L4 수준 대표주자 TCP와 UDP

TCP와 UDP 개요

• TCP에만 연결(Connection ,Session) 개념이 존재함
• 연결은 결과적으로 순서번호로 구현된다.
• 연결은 "상태(전이)" 개념을 동반한다.
• TCP는 배려남 , UDP는 (배려가 없는) 나쁜남자에 비유할 수 있다.
  • udp는 연결이 확립된것과 상관없이 그냥 계속 보낸다.

연결은 논리적인 개념이다. 뭔가 물리적으로 , 전기적으로 연결되었다는것이 아님

client process가 socket을 open 하면 OS가 TCP port 번호를 하나 부여해준다. 그러면 server에서 연결대기하고 있는 곳으로 정확히 연결시도를 하면 연결이 되지만 그렇지 않으면 kernel 수준에서 거부한다.

---

TCP 연결 과정

• ip header , tcp header만 있고 payload가 없는 단순한 segment가 왔다 갔다 한다.
• client가 sequence number를 랜덤으로 생성해서 SYN으로 보내준다. 
• server도 자신의 sequence number를 랜덤으로 생성하고 client에게 받은 sn 을 1 증가시켜서 같이 보낸다.
• SYN+ACK 를 받은 client는 자신이 연결되었다는것으로 판단한다 = established
• ACK를 client보내고 Server가 받으면 연결이 되었다고 판단한다 = established

 

MSS (Maximum Segment Size) 가 얼마인지 서로 알려주게 된다. 

MSS가 서로 1460 MTU(Maximum Transmission Unit) 가 1500임을 가저하고 진행하게 되는데

둘중 한놈이 작으면 작은것에 맞춰서 진행하게 된다.

---

TCP 연결종료 및 상태변화

연결을 하는 놈이 client 였으니 종료도 client가 하는것이 일반적이다.

client 가 FIN + ACK 를 같이 보내서 연결을 끊어달라고 server에게 보낸다.

받았다고 ACK를 server가 보내고 자신은 CLOSE_WAIT으로 들어가게 된다.
server의 ACK를 받은 client 는 FIN_WAIT2에 들어가서  server의 FIN+ACK 을 기다리게 된다.

server가 FIN + ACK를 보내고 LAST_ACK를 기다리는 상태로 변한다.
client는 TIME_WAIT 상태로 들어가게 된다. TIME_WAIT 발생하는곳이 먼저 종료를 요청한 쪽인것이다.
server가 TIME_WAIT가 발생한다면 일반적인 방법이 아님을 알 수 있다.

client가 TIME_WAIT으로 변경되면서 마지막 ACK를 보내게된다.
server가 ACK를 받고 종료하게 된다.

client는 TIME_WAIT의 시간이 지나서 CLOSED가 되면 socket이 회수되게 된다.
시간이 지나야만 닫히게 되어있기 때문에 Server가 자신이 먼저 연결을 끊는 상태가 되면 일정시간 동안 의도치 않게 socket 자원이 낭비가 될 수 있다.

MSL(Maximum Segment LifeTime) 이 TIME_WAIT의 시간이다.

그래서 보통 server가 직접 끊는게 아니라 client에게 좀 끊어라~ 라고 메시지를 전달해서 client가 직접 끊도록 유도한다.

---

TCP, UDP 헤더형식과 게임서버 특징

한 줄에 32bit 이니 source , destination port각각 16bit 씩 할당 되어 2^16 = 65535 까지 숫자를 할당 할 수 있지만 실제로 는 0 , 65535는 쓰지 않으므로 2^16 - 2 가지 의 숫자가 할당됨

sequence number = 밑에 발깐 부분의 data 사이즈에 따라 sequence number가 증가하게 된다.  1460bytes를 보냈으면 1460만큼 증가하게 된다.

data offset = tcp payload의 위치를 계산하기 위함

window size = tcp 수준에서 buffer의 공간에서 남은 여유 공간을 의미한다.
window size == 0이면 네트워크 pub이 프로그램의 sub을 능가한 것이다. 이때에는 프로그램 영역에서 해결해줘야한다.

 

UDP는 혼잡제어, 수신측의 buffer의 남은 용량(window size) 같은 것들을 전혀 고려하지 않고 그냥 보낸다.

IPTV의 영상 송출해주는 서버에서는 연결 된 클라이언트들의 각각의 네트워크 속도를 고려해서 하향 평준화 하는 것이아니라 빠른 네트워크를 쓰는 client들이 손해 보지 않게 그냥 왕창 빠르게 udp로 보내게 된다.

게임서버를 tcp를 이용해서 동기화를 하면 하향평준화하는 방법 밖에 없다.
그래서 보통 udp를 통해 동기화를 하게 된다.
client중에 느린 네트워크를 쓰는 놈은 뚝 뚝 끊기게 된다. 

HTTP3 에서도 UDP가 활용이 되게 된다.

---

TCP '연결'이라는 착각

파일 다운로드 중 LAN 케이블을 분리했다가 다시 연결하면 TCP 연결은 어떻게 될까?

tcp 연결은 유지가 된다. 너무 오래 뽑으면 안된다함

RFC표준과 운영체제 구현이 좀 다르다. 그래서 상단 process 부분에서 연결에 관한것을 지속적으로 검사하게 된다.
마치 친구랑 밤에 전화 할때 중간에 깨어있냐고 물어보는것과 비슷하다.

 

• 재전송 타이머의 기본 근사 값은 대략 3초다. 하지만 대부분의 운영체제들은 1초 미만이다.
  • 재전송의 예는 client 가 syn을 보냈을 때 server가 ack을 안보내주면 다시 syn을 재전송한다.
• 재전송 타이머 만료 후에도 확인 응답을 받지 못한 경우 세그먼트를 재전송하고 RTO(Retransmission Time Out) 값은 2배씩 증가하게 된다. 1 2 4 8 16 이런식으로
• 최대 5회 재전송을 시도하고 5회 이상 모두 실패할 경우 보통 전송 오류가 발생한다.