UDP, TCP

UDP

• L4 Transport 프로토콜
• 단순하고 빠르다. 연결지향 X / 데이터 전달 보증 X / 순서보장 X
• IP에서 Port와 체크섬만 추가된 개념
• 커스터마이징이 용이함

TCP

• L4 Transport 프로토콜
• 데이터 단위 : 세그먼트
• 논리적인 연결임을 기억하자.
  • LAN 케이블을 분리했다가 다시 연결해도 TCP 연결은 일정시간동안 연결되어 있다. 무선 연결을 생각하면 더 쉽다
• 커널 소켓은 두 개의 버퍼를 가지고 있다
  • 송신용으로 준비한 send socket buffer
  • 수신용으로 준비한 receive socket buffer
• 소켓과 연결된 TCP Control Block(TCB) 구조체가 있다.
  • TCB에 있는 데이터는 connection state(LISTEN, ESTABLISHED, TIME_WAIT 등), receive window, congestion window, sequence 번호, 재전송 타이머 등이다.
• 매 Packet을 수신 할 때 마다 ACK를 보내는건 비효율적이기도 해서 일정 주기마다 ACK가 전송 된다.
• 수신자로부터 ACK를 받지 못하면 송신자가 데이터를 재전송한다.
  • 따라서 송신자는 수신자로부터 ACK를 받지 않은 데이터를 보관한다 : buffer unacknowledged data

• 송신자는 수신자가 받을 수 있는 만큼 데이터를 전송한다.
  • 수신자가 자신이 받을 수 있는 바이트 수(receive window : 사용하지 않은 버퍼 크기)를 송신자에게 전달한다.
  • 만약 사용하지 않은 버퍼크기가 0이라면 송신 측 데이터 전송은 중지되고, receive window의 상태를 점검하기 위해 송신측에서 일정 간격으로 패킷을 보낸다. 
• 네트워크 정체를 방지하기 위해 congestion window를 사용한다.
• RTT : round trip time
• RTO : retransmission timeout 재전송 타이머 시간
  • RTT값은 RTO 값을 결정하는데 아주 중요한 요소이다.

연결설정

• SYN (세그먼트 번호 랜덤으로 세팅)
• SYN + ACK (세그먼트 번호 랜덤으로 세팅한 값 / 아까 받은 세그먼트 번호 +1)
• ACK (아까 받은 세그먼트 번호 +1)

연결종료

• FIN
• ACK
• FIN
• ACK
  • 위의 그림에서 Server는 마지막 ACK를 받고 소켓 종료
  • Client는 time_wait 시간만큼 지나고 나서 소켓 종료
    • Server가 ACK를 못받으면 다시 FIN을 보내게 되는데, 혹시 그런 상황일까봐 기다리는 것

✅ TCP 속도

• TCP 속도를 높이기 위해서는 Window Size(수신자의 ACK 없이도 송신자가 한번에 보낼 수 있는 데이터)를 키워야 한다.
• Tx Socket Buffer가 꽉 차 있으면 유저 어플리케이션은 TCP 계층으로 데이터를 내려 보낼 수 없다.
• NIC 버퍼가 꽉 차 있으면 Tx Socket Buffer는 NIC 버퍼로 보낼 수 없다.
• Rx Socket Buffer가 꽉 차 있으면 NIC 버퍼의 데이터를 Rx Socket 버퍼로 보낼 수 없다.
• Rx Socket Buffer는 읽어가는 속도보다 들어오는 속도가 빠르면 꽉 채워질 수 있다.
  • Rx Socket Buffer가 꽉 찼다면 더이상 데이터를 받아 들일 수 없으므로 데이터가 유실 될 가능성이 있다. -> Flow Control
    • Rx Socket Buffer의 빈 공간 크기를 송신자에게 알려주고, 송신자는 그 크기가 넘치지 않을만큼만 계산해서 데이터를 전송한다.
    • 꽉 차게 된다면 Zero Window로 보낸다.
    • Zero Window를 받은 송신자는 수신자로부터 다시 데이터를 보내도 좋다는 다른 세그먼트를 받으면 데이터 전송을 다시 할 수 있다.
      • Window Based Flow Control
• Tx Window (Send Window)
  • ACK 없이도 한번에 보낼 수 있는 최대 데이터량 
  • TCP 송신자 측의 TCP 계층에서 소프트웨어가 관리하는 변수값
  • 대부분 수신자가 알려주는 Receive Window 값을 그대로 사용한다.
    • 따라서 Send Window <= Receive Window이다.
  • 패킷이 유실되는 상황이라면 Send Window는 Congestion Window와 같은 값이 된다.
    • 패킷 유실이 발생하면 재전송을 해줘야 한다. 따라서 재전송을 위해서는 ACK를 받기전까지 Retransmission Queue에서 삭제할 수 없다.
    • 즉 Retransmission Queue보다 더 큰 데이터를 보낼 수 없다.
    • 따라서 Send Window <= Retransmission Queue이다.
• 속도가 안나오는 이유
  • Receive Window가 작아서
  • Retransmission Queue가 작아서
  • 패킷 유실이 발생해서 Congestion Window가 작은 값이 되어서

Window Scaling

• 2Bytes로 고정된 TCP 헤더의 Window Size 제약을 극복하기 위한 옵션
• 최대 값 : 64KBytes
• 커넥션이 맺어질 때 SYN, SYN/ACK 단계에서 서버와 클라이언트는 TCP 옵션을 주고 받는다
  • 윈도우 스케일 옵션은 SYN 패킷에만 있다.
• TCP Option Window Scale의 숫자를 2의 멱승한 값과 Window Size를 곱한 값이 TCP 수신자가 전달하는 실제 Window Size이다.

Sliding Window

• TCP 송신자는 송신을 시작하게 되면 Send Window를 초과하기 전까지 데이터를 전송한다.
• 송신자가 수신자로부터 새로운 Window Size를 알려주는 ACK 메세지를 받는 시점은 다음과 같다.
  • 초기 Window Size가 10000이라고 가정해보자
    • Window Size만큼 모두 데이터를 전송하기전
      • 7500bytes를 보낸 시점 / ACK 1501, Window Size 10000 받음
      • 6000bytes는 받지 못했다고 나옴. 1500 + 6000 으로 생각하고 10000 -6000 = 4000bytes를 추가로 보낼 수 있다.
    • Window SIze만큼 전송한 시점
      • 10000bytes를 보낸 시점 / ACK 1501, Window Size 10000 받음
      • 1500 + 8500 이라고 생각하고, 10000 - 8500 = 1500bytes를 추가로 보낼 수 있다.
    • Window Size만큼 모두 전송한 이후
      • 10000bytes를 보내고 몇초후에 / ACK 1501, Window Size 10000 받음
      • 1500 + 8500 이라고 생각하고, 10000 - 8500 = 1500bytes를 추가로 보낼 수 있다.
• 즉, 수신자의 Rx Socket Buffer Overflow가 나지 않도록 송신자의 전송량을 Control하는 메커니즘

Congestion Control

• 네트워크에서 Congestion이 발생한 것을 감지해서 Congestion을 경감시키기 위한 알고리즘
  • Congestion : 네트워크 장비 트래픽 임시 저장 공간이 꽉 차서 넘치는 것
  • 트래픽을 처리하는 속도가 트래픽이 들어오는 속도를 감당하지 못해서 넘치는 상황
  • TCP는 Congestion과 물리적 에러로 데이터가 드랍이 발생한 상황을 구분하지 못한다.
    • TCP Retransmission Timeout이 발생하면 TCP는 네트워크에서 congestion이 발생했다고 인지한다.
      • TCP는 매 패킷 전송시마다 Retransmission Timer를 구동시킨다. 그때까지 ACK가 수신되지 않으면 TCP는 Congestion이 발생해 패킷이 드랍된 상황으로 판단한다.
    • 동일한 ACK 패킷이 연속해서 3번 수신된 경우
      • TCP 수신자는 패킷 하나가 누락되고 다른 패킷이 수신되면 드랍된 패킷을 재전송해달라는 의미로 드랍된 패킷에 대한 ACK를 다른 패킷 수신에 대한 ACK로 보낸다
        • 1,2,4,5,6이 들어오는 경우 3이 오지 않았음으로 4->3 / 5->3 / 6->3으로 보낸다
• != Flow Control(Sliding Window)과 다르다
  • Rx Socket Buffer가 꽉 차서 넘치는 것을 방지하기 위한 알고리즘
• Congestion 상황이라고 인지되면 Congesion Window를 Congestion이 발생하기 바로 이전의 Window Size 절반으로 줄인다.

컴퓨터 네트워크에서 데이터가 이동하는 과정

Disk에 있는 데이터를 FTP를 이용해 내려 받는 경우를 가정해보자

• User Space에서 동작하는 FTP 어플리케이션은 디스크에 있는 데이터를 읽어서 전송하기 위해 read() 시스템 콜을 사용한다.
• 커널에서 Disk에 있는 데이터를 커널 메모리 버퍼로 읽어 들인다
• 커널 메모리에 읽어 들인 데이터가 User Space의 버퍼 메모리로 카피된다.
• FTP 어플리케이션이 디스크에서 읽어온 데이터를 네트워크로 전송하려고 하면, 해당 데이터를 Tx Socket Buffer로 카피한다.
  • Tx Socket Buffer에서 전송된 세그먼트는 ACK가 돌아올때까지 retransmission queue에서 대기한다.
  • ACK가 오면 삭제된다.
• 데이터의 사이즈가 TCP의 MSS보다 작으면 IP 레이어를 호출하고, 더 크다면 MSS로 자르고 각 세그먼트에 header를 추가해 순서대로 IP 레이어 함수를 호출한다,
  • MSS : TCP 헤더를 제외한 데이터 최대 크기
    • TCP 커넥션이 맺어지는 3way handshake 단계에서 SYN, SYN/ACK 패킷 옵션으로 TCP 송신자와 수신자가 서로 주고 받는다.
    • 이렇게 주고 받은 MSS에서 더 작은 값을 송신자와 수신자에서 모두 MSS 값으로 사용된다.
    • TCP가 옵션으로 주고 받는 MSS는 IP 단편화가 발생하지 않는 크기를 서로 교환하기 때문에, 일반적으로 TCP의 경우 IP 단편화가 발생하는 경우가 없다.
• 커널 스택에서 IP 레이어, MAC 레이어를 거친 데이터는 커널 메모리에서 NIC 버퍼로 카피된다.
• NIC로 전송된 데이터는 네트워크를 통과해서 수신측 NIC으로 전달된다.
• NIC 버퍼에 수신된 데이터는 Rx Socket Buffer로 카피된다.
• FTP 어플리케이션에서 read() 함수를 이용해 데이터가 수신되면 읽어들인다. 이때 Blocking 모드로 데이터가 버퍼에 들어오기를 기다린다.
• 커널의 TCP 레이어에서는 Rx Socket Buffer에 데이터가 도착하면, 유저 메모리 공간에 카피하고 FTP 어플리케이션이 데이터를 읽어가도록 한다.
• FTP 어플리케이션에서는 수신된 데이터를 로컬 디스크에 저장한다.

하트비트

• 다른 시스템에게 살아있음을 알리는 신호
• 주기적으로 전송, 수신측에서 하트비트를 받지 못하면 송신측 시스템이 장애가 발생했다고 인지 가능

읽어봐야 할 책

• TCP/IP Illustrated 
• 네트워크 트러블슈팅 가이드(저자 장혁)

👍 Reference

https://blog.naver.com/goduck2/220076011565

[오리뎅이의 TCP 이야기 - 0] TCP 속도(Throughput)는 어떻게 구해지나요?

https://d2.naver.com/helloworld/47667