직접 설명해보는 TCP/IP 송수신 원리

 

※  아래 내용은 스스로 공부한 내용을 정리한 글입니다.      ※  때로 정확하지 않을 수 있으며, 참고만 부탁드립니다.      ※  잘못된 내용이 있을시 댓글로 알려주시면 감사하겠습니다.

 

 

 

※ 노란 형광펜은 궁금점, 회색 형광펜과 파란 형광펜은 궁금점 해결에 대한 표시 입니다. 

 

 

 컴퓨터 구조는 세 부분으로 이루어진다. OS 수준의 User application (User mode)과 System S/W인 Kernel, 그리고 H/W 영역이다. 이 영역에 OSI 7 Layer가 위치한다. Kernel에는 Network 계층 L3와 Transport 계층 L4가 위치하고 있고,  User application에는 L5, L6, L7이 위치한다. 이를 더 간소화하여 네 개의 계층으로도 설명할 수 있다. User application에는

Application 계층, Kernel에는 Transport와 Network 계층, H/W 영역에는 Network Access계층, 이렇게 총 네 개의 계층으로도 이해할 수 있다.

 여기까지는 컴퓨터 구조 위의 추상적인(abstract) 네트워크 설명이다. 이를 구현한(Implement) 예시를 들어보자. User application 상에서 HTTP 프로토콜을 통해 프로세스 하나를 가동하고, Kernel에는 TCP, IP 프로토콜이 구현되어 있다고 가정한다. 그리고 H/W 영역에는 NIC (Network Interface Card)라는 하드웨어를 움직일 수 있는 Device Driver가 존재한다고 가정하자. 이때 프로세스에는 File이 존재한다. TCP/IP라는 커널의 한 부분을 User mode application로 추상화할 때는 File의 형태로 추상화한다. 만약 커널의 한 부분이 Network와 관련되어 있으면 File이라고 하지 않고 Socket이라고 부른다. 즉 TCP IP Socket이라고 할 수 있다. TCP를 User mode application이 접근할 수 있도록 추상화한 인터페이스가 소켓이다. 

 

왜 소켓이 필요한가?

낮은 단계에서 구현한 tcp는 구현 세부사항(Implement specification)을 포함하고 있다. 이것은 응용 계층에서 굳이 알 필요가 없다. tcp를 응용계층에서 쉽게 사용할 수 있도록 소켓이라는 자료형(혹은 구조)를 새롭게 만드는 것이다.

---

상황 가정 2

 클라이언트와 서버 간의 TCP / IP 연결이 되어 있고, 클라이언트가 서버 측에 파일 다운로드를 요청한 상황을 가정해보자. 3-way handshake로 상호 간 연결이 확인된 상태이다. 서버에서는 파일 하나를 클라이언트로 보내주어야 한다. 서버의 프로세스가 구동 중이고, 소켓이 열려있어 클라이언트와 통신 중이다. 위에서 말했듯 여기서도 Network(TCP/IP)와 관련되어 있으니 File 또한 Socket이라고 부른다. 이때 구동 중인 프로세스가 파일에 할 수 있는 Operation은 RWX(읽기, 쓰기, 실행하기)이다. 소켓 통신일 때 RW를 각각 receice, send라고 부르며 이 때 서버 프로세스가 소켓에 I/O 할 수 있다.

 서버 측의 HDD에는 A.bmp라는 파일이 저장되어 있다. 이 파일의 크기는 1.4 MB라고 하자. Kernel의 File System으로 파일을 관리하고 있고, HDD내의 Device driver를 통해 File System과 정보를 서로 주거니 받거니 하는 중이다. 서버의 User mode에는 메모리가 할당되어 있고, 메모리 크기는 개발자가 직접 정한다. 이 메모리를 buffer#1이라고 하고,  사이즈는 64 KB라고 하자. 대게 이 사이즈는 실제 파일 크기보다 작다 (왜?) 

 소켓에서 kernel mode, 즉 TCP에 닿아있는 부분에서는 클라이언트에 보내기 위한 첫 작업(?)을 시작한다. 파일에 대한 분해가 시작된다. 이 TCP에도 메모리가 존재하며 이를 buffer#2라고 하자. 여기는 user mode 상의 buffer#1에 64 KB 만큼이 buffer#2로 복사가 일어난다. 여기까지의 입출력이 Buffered I/O이다. 이 TCP 메모리인 buffer#2는 IP단으로 내려온다. IP 패킷으로 segment가 만들어지는데, 이는 예를 들어 "copy"라는 64 KB의 데이터가 "c" "o" "p" "y" 하나씩 잘리는 것을 의미한다. 그리고 이것들을 순서대로 정렬할 수 있는 어떤 규칙을 가진 번호가 매겨진다. (실제 1,2,3 같은 숫자는 아니다. 그럼 뭐?) 즉 "copy blahblah sfjsdfdsf"라는 파일 전체에서 64 KB만큼의 "copy"로, 이것은 다시 "c" "o" "p" "y"로

 (갑자기 급 추상적 비유적 설명) 패킷은 "c"라는 작은 조각이 들어있는 택배 박스이다. 이 택배 박스는 택배 트럭에 올라타는데, 이 택배 트럭은 Frame이다. L2로 내려오며 Frame이 되는 것이다. 택배 기사는 어떻게 하면 잘 전달할지에 관심이 있다. 클라이언트로 넘어가는 과정에서 트럭을 몇 번 갈아타기도 하는 Frame 바꿔치기가 일어나고, 없어지기도, 다시 생기기도 한다. 

 클라이언트에 트럭이 도착하면 택배 박스가 꺼내지고, 택배를 만들었던 과정 거꾸로 택배가 이동한다. 먼저 decapsulation이 일어나고 택배에 들어있던 작은 데이터 조각이 튀어나온다. Device Driver에서 IP로 이동하는 경계에서 Frame이 없어지고 Packet이 된다. 그리고 이 Packet은 TCP로 올라가며 Segment가 된다. 마찬가지로 클라이언트 소켓, TCP에도 메모리(buffer)가 존재하며, 택배 박스에서 튀어나왔던 Segment가 TCP buffer에 차례로 쌓이게 된다. TCP buffer에 쌓이는 과정을 자세히 보자.

  맨 첫 번째 Segment가 도착하면 클라이언트는 서버에 ACK를 보낸다. 이는 데이터를 잘 받았으니 다음 것을 보내라는 신호이며, 이 신호에는 window size에 대한 정보가 들어있다. window size는 TCP buffer의 크기를 말한다. TCP buffer는 서버에서 날아오는 Segment를 집어넣는 공간이고 크기는 정해져 있다. 서버는 첫 번째 데이터를 보낸 후 ACK가 올 때까지 Wait 할 수밖에 없다. 따라서 속도의 지연이 발생한다. 

 왜 window size를 보내야 하는가? 만약 서버가 다음에 보낼 Segment 사이즈가 window size보다 크면 어떻게 되는 것일까? 그렇게 되면 TCP buffer에 다음 Segment를 넣지 못하게 될 것이고, 결국 클라이언트에 파일을 보낼 수 없지 않을까. 따라서 이 window size에 대한 정보는 아주 중요하다. 클라이언트의 window size가 MSS (Maximum Segment Size) 보다 큰지 따져서 충분히 크면 다음 것을 보내고, 그렇지 않으면 기다린다(wait).

 TCP buffer는 크기가 정해져 있다. 뒤이어 도착할 Segment의 크기가 더 크다면 TCP buffer는 넘쳐나고 만다. 서버에서 보내는 Segment를 담지 못할 것이다. 다행히도, 클라이언트는 Segment가 도착하면 최대한 빨리 user mode상의 buffer, 즉 File I/O buffer에 퍼올리는 작업을 한다. 이 작업은 클라이언트 프로세스가 소켓 RW 중 Receive 한다고 해서, read 속도라고도 한다. read 속도는 network 속도보다 빨라야 하는데, 이는 지연(wait)이 발생하지 않기 위해서는 다음 Segment를 빠르게 보낼 수 있도록 TCP buffer를 넉넉하게 유지하는 것이 중요하기 때문이다. 만약 read 속도가 더 느리면 TCP buffer의 남은 공간이 점점 줄어들 것이고, Segment를 받지 못하니 서버에서는 보낼 수 없게 된다. (window size는 앞의 segment를 넣고 남은 공간을 말하는 건지, 아니면 TCP buffer 전체 크기를 말하는 건지?) 이 window size를 잘 체크하면 네트워크에서 application의 문제를 잘 파악할 수 있다. (어떻게??) 

 

window size는 앞의 segment를 넣고 남은 공간을 말하는 건지, 아니면 TCP buffer 전체 크기를 말하는 건지?

상황에 따라 데이터가 소비되는 속도가 다르기 때문에 빈 공간은 때에 따라 다르다.

따라서 receiver는 sender에게 계속 window size를 알려줘야 한다.

 

 

 

---

[ Reference ]

중심 내용은 널널한 개발자 TV를 참고하고, 그 밖의 궁금한 것들은 리차드 스티븐스의 TCP/IP Illustreated Volume 서적, 동료 간의 질의응답을 통해 공부하고 있습니다.