이 문서는 유튜브 '널널한 개발자 TV'님의 강의를 토대로 작성되었습니다.
#1 TCP/IP 송/수신 원리
Process(Server)가 File(Socket)에 할 수 있는 동작은 기본적으로 Read, Write, X 이다.
소켓통신에 실행 개념은 없다.
소켓통신 Read : Receive (Input)
소켓 통신 Write : Send (Output)
보조기억장치에 있는 1.4MB의 데이터를 소켓을 통해서 Send해야하는 상황 :
1. Process의 Socket에 일정 메모리를 할당한다. Buffer#1(<1.4MB)
(64KB를 할당한다고 가정)
2. 1.4MB 원본데이터를 64KB단위로 분해하여 프로세스에 할당된 메모리에 쌓는다.
File을 Read한 것이다.
3. Socket은 TCP/IP를 추상화 한 것. Socket의 끝 단에서 분해가 일어날 것이다.
4. TCP에도 Buffer#2 있다. Buffer#1의 데이터를 Buffer#2에 Copy를 한다.
버퍼에서 버퍼로 이동하는 입출을 Buffered I/O 라고 한다.
5. TCP에서 IP로 데이터가 이동할 때 Buffer#2의 데이터를 잘게 쪼갠다. 이를 세그먼트(Segment)라고 부른다.
이 시점에 Segment에 번호를 붙인다. 이 데이터는 Packet이라는 데이터로 캡슐화 된다.
6. Packet을 NIC수준으로 이동하면서 L2수준으로 내려오면 Frame 이라는 데이터 형태로 캡슐화 된다.
프레임은 데이터가 전송되는 과정 속에서 생겼다 사라졌다를 반복한다.
서버로부터 클라이언트가 데이터를 Receive 하는 상황 :
1. 클라이언트의 Process와 연결된 Socket에도 File I/O Buffer가 있다.
2. TCP도 TCP Buffer를 가지고 있다.
3. Frame이 NIC에 도착해서 Kernel mode로 데이터가 이동할 때 역캡슐화가 발생한다.
4. 데이터가 IP수준에서 Packet데이터 형태로 있으며, TCP수준으로 이동하며 역캡슐화가 발생한다.
5. TCP수준에서 Segment 데이터가 되어서 TCP Buffer에 쌓인다.
6. 대략 Segment가 2개정도 도착하면 서버에 ACK 번호를 전송한다.
서버는 2개의 Segment를 전송하고 PC의 ACK 번호를 기다리고(Wait) 있는 것이다.
> 속도 지연 발생
7. TCP Buffer의 크기를 Window Size라고 한다.
8. 수신측에서 Segment를 받으면 저장할 수 있는 공간.
9. ACK 데이터에 Window Size를 포함한다.
Window size > MSS(Maximum Segment Size) 라면 Send
Window size < MSS(Maximum Segment Size) 라면 Wait
10. TCP Buffer에 Segment는 계속 쌓인다. TCP Buffer에서 File I/O Buffer로 이동시키는 속도가 네트워크 수신속도 보다 느려지면 Window Size의 여유공간이 줄어든다. 여유공간이 부족하면 서버는 데이터를 보내지 못한다.
소켓 프로그래밍에서 중요한 점
처리지연의 문제를 해결하기 위해서 TCP Buffer에서 File I/O Buffer로 Read하는 속도를 체크해야한다.
송신측의 문제가 아니라 수신측의 문제일 수 있다는 점을 알아야한다.
#2 TCP 연결?

Sequence number : 송신측에서 Segment에 부여하는 번호
32bit로 표현할 수 있는 최대 메모리 크기 = 2^32 * bytes = 4GB
TCP Flags : 예약 다음에 있는 데이터.
A : 0x10 Ack
S : 0x02 Syn
'연결' 이란? TCP 연결에 보안성이 없다.
보안성에 대한 고민을 해봐야한다.
3-Way handshake

단위는 Segment이다. 보안성이 없다.
3-Way handshake란 Seq번호를 교환하는 행동이다. 이 때 MSS(Maximum Segment Size)도 교환한다.
혼잡 제어에 대한 정책을 교환한다. SACK
#3 Network에 충격이 발생하면 TCP 연결은 어떻게 될까?
물리적으로 NIC와 LAN의 연결을 끊으면 이를 Network 충격 이라고 한다.
유선에서는 충격이 발생할 일이 많지 않지만, 무선에서는 자주 발생한다.
(기지국을 갈아탈 때마다 충격이 발생한다.)
그런데 충격이 발생해도 TCP 연결이 일정시간 유지된다. 75초
왜 그럴까? 이는 Virtual이라 논리적으로 연결이 유지되는 것이다.
그렇다면 게임서버에서는 이를 어떻게 관리해야 할까?
서버가 유저에게 네트워크 충격이 발생했는지 매번 확인해야한다. keep-alive 메커니즘.
MMORPG 아이템 복사 버그
서버가 빠른 동작을 위해서 DB에 바로 연결하지 않고 인메모리를 따로 두어 응답속도를 빠르게 했다.
네트워크 충격에 대한 TCP 연결 유지시간이 짧지 않았다.
두 유저가 유일한 아이템을 LAN선을 뽑는 행위를 통해 TCP연결을 유지한 채 아이템을 2개 존재하는 상황을 만들었다.
L1~L2 충격을 L3~L4연결에서 어떻게 대응할 지 고민해봐야 한다.
HTTP는 Stateless 이다. 이런 속성은 연결에 있어서 자유롭거나 너무 쉽게 해킹당할 수 있다.
긴 글 읽어주셔서 감사드립니다.
22.12.10
'TIL (Today I Learned) > 컴퓨터 시스템(CS)' 카테고리의 다른 글
[CS] 네트워크 기초, L2 스위치 그리고 TCP 장애 #6 (1) | 2022.12.10 |
---|---|
[CS] 네트워크 기초, DNS #5 (0) | 2022.12.10 |
[CS] 네트워크 기초, Proxy #3 (1) | 2022.12.10 |
[CS] 네트워크 기초, 네트워크 망 #2 (0) | 2022.12.10 |
[CS] 네트워크 기초, TCP/IP 4계층, #1 (1) | 2022.12.10 |
댓글