[네트워크] TCP, UDP

TCP (Transmission Control Protocol)

• unreliable network에서, reliable network를 보장할 수 있도록 하는 프로토콜
• 송신자와 수신자가 모두 소켓이라는 종단점을 생성함으로써 이루어다.
• TCP의 연결 설정은 3-way hand shake를 통해 이뤄진다.
• full-duplex : 전송이 양방향으로 동시에 일어날 수 있다.
• point to point : 각 연결이 정확히 2개의 소켓을 가지고 있음을 의미한다. 멀티 캐스팅이나 브로드 캐스팅을 지원하지 않는다.
• 소켓 사이에 바이트 스트림을 전송하도록 설계 되어 신뢰성이 보장된다.
  • 메시지가 유실되지 않고 메시지가 내려온 순서대로 전송된다.
• 연결지향적이다.
• 흐름제어, 혼잡 제어 기능을 한다.

TCP 흐름제어

상대방이 받을 수 있는 능력에 따라 보내는 속도를 조절하는 것을 흐름제어라고 한다. receiver가 sender에게 자신의 저장 상태를 피드백한다. 수신 측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실 될 수 있으며, 만약 손실 된다면 불필요하게 응답과 데이터 전송이 송/수신 측 간에 빈번히 발생한다. 이를 방지하기 위해 송신 측의 데이터 전송량을 수신측에 따라 조절해야한다.

해결 방법

stop and wait

매번 전송한 패킷에 대해 확인 응답을 받아야만 다음 패킷을 전송하는 방법

Sliding Window

수신측에서 설정한 왼도우 크기 만큼 송신측에서 확인 응답 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어 기법

어플리케이션에서 리드 콜이 있으면 리시브 버퍼에서 패킷들을 어플리케이션으로 올려보내는데, 리드콜의 속도는 애플리케이션 계층에 달려 있기 때문에 send buffer에서는 receiver가 리드하는 속도를 고려해야한다. 이를 위해서는 receive buffer에 남아 있는 공간, receive window를 sender 측의 send buffer 쪽으로 보내주고 이를 TCP 헤더에 저장해놓으면 된다. send buffer의 window 또한 receive window 사이즈에 의존적이게된다.

윈도우에 포함되는 모든 패킷을 전송하고 각 패킷들의 전달이 확인되는 대로 이 윈도우를 옆으로 옮김으로써 그 다음 패킷을 전송한다.

TCP 혼잡 제어

네트워크 상황에 맞춰서 보내는 패킷의 양을 조절해주는 것이다. 네트워크가 처리할 수 있는 양보다 더 많은 양의 데이터가 보내졌을 때 생기는 현상을 congestion이라고 한다.

해결방법

AIMD (Additive Increase / Multiplicative Dcrease)

처음에 세그먼트를 보내고 그에 대한 피드백을 제대로 받으면 congestion window의 크기를 보낸다. 선형으로 증가하다가 네트워크에 문제가 생기는 순간에는 cwnd의 크기를 절반으로 줄인다.

공평한 방식으로 여러 호스트가 한 네트워크를 공유하고 있으면나중에 진입하는 호스트가 처음에는 불리하지만 나중에는 평형상태로 수렴하게 되는 특징이 있다.

문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 되고 네트워크가 혼잡해지는 상황을 미리 감지못한다. 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이다.

Slow Start

제일 처음에 시작할 때는 세그먼트 하나를 보낸다. 이후에는 세그먼트를 지수적으로 늘려가면서 보내다가 임계점(ssthresh)에 도달하면 additive increases로 스위칭한다. 경험적으로 congestion이 발생할 가능성이 있기 때문이다. 이 단계를 congestion aviodance라고 한다.

Fast Retransmit (빠른 재전송)

• 패킷을 받는 쪽에서 먼저 도착해야할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보내게 된다.
• 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK 패킷에 실어서 보내게 되므로, 중간에 하나가 손실되게 되면 송신 측에서는 순번이 중복된 ACK 패킷을 받게 된다. 이것을 감지하는 순간 문제가 되는 순번의 패킷을 재전송 해줄 수 있다.
• 중복된 순번의 패킷을 3개 받으면 재전송을 하게 된다. 약간 혼잡한 상황이 일어난 것이므로 혼잡을 감지하고 window size를 줄이게 된다.

Fast Recovery (빠른 회복)

혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법이다. 이 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD 방식으로 동작하게 된다.

TCP 3-way handshake

TCP는 3-way handshake를 통해서 양쪽이 TCP connection을 맺었음을 agreement한다.

connection

1. 클라이언트가 서버에 접속을 요청하는 TCP SYN을 보낸다
2. 서버는 요청을 수락한다는 응답으로 SYN과 ACK을 보낸다.
3. 클라이언트에 TCP 자료구조가 생성되고 완료됐다는 뜻으로 클라이언트는 서버에 ACK 메시지를 보낸다.

closing connection

데이터를 다 주고 받았다면 모든 자료구조를 해체해야한다.

1. 어플리케이션에서 클로즈 콜이 오면 클라이언트는 FIN 메시지를 보낸다.
2. 이에 대한 응답으로 서버는 ACK 메시지를 보낸다.
3. 서버에서도 FIN 메시지를 보낸다.
4. 이에 대한 응답으로 클라리언트는 ACK 메시지를 보낸다. 이 때 클라이언트는 바로 자료 구조를 없애는 것이 아니라 ACK이 유실될 상황에 대하여 TIMED_WAIT 시간을 가진다.

왜 syn, ack?

요청과 응답에 대한 패킷을 주고 받아야하기 때문에 두 종류이다.

왜 3-way?

클라이언트가 서버에게 자신의 목소리가 들리냐고 물어본다. (SYN)

서버는 들린다고 말한다. (ACK) 그리고 서버는 자신의 목소리가 들리냐고 클라이언트에게 물어본다. (SYN)

클라이언트는 서버 목소리가 들린다고 말한다. (ACK)

이렇게 양방향으로 소통해야하기 때문이다.

왜 randomed sequence number?

처음 클라이언트에서 syn 패킷을 보낼 때 자기 자신의 최초의 시퀀스 넘버를 채워서 보내는데 이 수가 난수인 이유는 포트가 재사용되기 때문에 순서대로 보낼 경우 이전 connection으로 서버가 잘못 인식할 수 있기 때문이다.

UDP(User Datagram Protoco)

• 비연결형, 신뢰성 없는 전송 프로토콜이다.
• 데이터 처리가 빠르기 때문에 주로 실시간 방송과 온라인 게임에서 사용된다.
• connection을 유지할 필요가 없으므로 오버헤드가 적기 때문에 DNS에서 사용한다. DNS의 경우 요청이 작고 신뢰성 문제를 어플리케이션 계층에서 해결할 수 있기 때문이다. 하지만 요청 데이터가 크거나 응답을 못 받은 경우, DNS 서버 간의 요청을 주고 받을 때 사용하는 Zone transfer를 사용할 경우에는 TCP를 사용한다.

TCP , UDP

왜?

IP의 역할은 Host to Host만을 지원한다. 하나의 장비 안에서 수 많은 프로그램들이 통신할 경우 한계가 있다.

=> 포트로 해결

IP에서 오류가 발생한다면 ICMP에서 알려주지만 대처는 못하기 때문에 IP 상위 레벨에서 처리해줄 프로토콜이 필요하다.

=> TCP, UDP로 해결