겸손하기 꾸준하기 건강하기
서버-클라이언트 모델에서 데이터는 어떻게 전송되는가 🚎 본문
스터디 발표 자료입니당 :-P
이해하면 인생이 바뀌는 TCP 송수신 원리 수강 후, 작성되었어요 😊
오늘 발표하는 내용을 이해하려면 ①전송 계층, ②계층별 데이터 명칭, ③ 네트워크 기기에 대한 짧은 지식이 있어야 하기 때문에, 간단하게 정리하고 가봅시다~ 😊
TCP/IP 4 계층 vs OSI 7 계층
두 모델은 기본적으로 데이터 통신 서비스를 제공하는 모델로, 오늘은 TCP/IP 4계층을 기준으로 설명해 보겠습니다.
4 계층 모델은 네트워크에서 사용되는 통신 프로토콜의 집합으로, 계층들은 프로토콜의 네트워킹 범위에 따라 네 개의 계층으로 추상화되어 있습니다. 즉, 계층 내부에서는 갈아 끼울 수 있다는 뜻입니다. (예: TCP ↔ UDP)
애플리케이션 계층 / 주로 응용 프로그램(Applicaion)끼리 데이터를 교환하기 위한 계층
전송 계층 / 송신자와 수신자를 연결하는 통신서비스를 제공하는 계층
인터넷 계층 / 네트워크 패킷을 IP 주소에 기반해, 지정된 목적지로 전송하기 위해 사용되는 계층 (비연결지향적. why? 연결은 전송 계층에서 담당하거든요.)
네트워크 계층 / 전선, 광섬유, 무선 등으로 실질적으로 데이터를 전달하고, 장치 간 신호를 주고받는 규칙을 정하는 계층
PDU (Protocal Data Unit)
PDU는 네트워크의 어떠한 계층에서 계층으로 데이터가 전달될 때 한 덩어리의 단위입니다. PDU는 제어 관련 정보들이 포함된 헤더(header), 데이터를 의미하는 페이로드(payload)로 구성되어 있으며, 계층별로 부르는 명칭이 다릅니다.
PDU는 각 계층을 거치면서 캡슐화, 역캡슐화 되고, 그때마다 명칭이 달라집니다.
상위 계층의 헤더와 데이터를 하위 계층의 데이터 부분에 포함시키고, 해당 계층의 헤더를 삽입하는 과정을 캡슐화 라 하며, 하위 계층에서 상위 계층으로 가며 각 계층의 헤더 부분을 제거하는 과정을 역캡슐화 라 합니다.
| 계층 | PDU 명 | 전송 주소 | 장비 |
| 응용 (Application) | 데이터 (Data) | - | |
| 전송 (Transport) | 세그먼트 (Segment) | Port | 게이트웨이 |
| 인터넷 (Ineternet) | 패킷 (Packet) | IP | 라우터 |
| 네트워크 (Network) | 프레임 (Frame) | MAC | 브리지, NIC, 스위치 |
"몇 계층 장비다"라는 것은, 캡슐화된 데이터를, 장치가 해석할 수 있는 계층까지 역캡슐화 하여 프로토콜의 내용을 확인하고 경로를 설정해 줄 수 있는 장비라는 뜻입니다.
예시를 볼까요?
라우터는 3 계층 장비입니다. (L3 스위치라고도 해요)
라우터는 인터넷 계층까지 역캡슐화 하고, 이때 PDU는 패킷입니다. 패킷은 라우터를 타고 이동을 하는 것이죠.
라우터를 통해 패킷이 이동 경로를 알 수 있고, 패킷이 전송되는 것입니다.
오늘 등장하는 장비들
의 얼굴을 알아볼게요..
Router
라우터는 서로 다른 네트워크의 통신을 담당하는 기기로, IP패킷을 해당 경로로 전달합니다.
NIC (Network Interface Controller)
NIC는 컴퓨터나 다른 네트워크 장치를 로컬 네트워크(LAN)에 연결하는 데 사용되는 하드웨어 구성 요소입니다. 이 카드는 물리적인 랜 케이블이나 무선 연결을 통해 네트워크와의 통신을 가능하게 해요. 데이터의 전송과 수신을 담당하며, 이를 위해 특정 식별 정보가 필요한데, 이 식별 정보가 MAC 주소인 거예요.
MAC 주소: 네트워크 상에서 각 장치를 식별하는 데 사용되는 고유한 식별자. NIC에 고정되어 있습니다.
NIC은 네트워크 접속을 가능하게 하며, 따라서 이 계층을 '네트워크 액세스 계층'이라고 부르게 됩니다~
자 그러면 이제, 본격적으로 서버-클라이언트 모델에서 TPC 송/수신에 대해 이야기해 볼까요~! 😀
오늘 이야기 해 볼 상황은 서버와 클라이언트가 TCP/IP 통신을 하는 상황이에요.
이미 서버와 클라이언트는 연결이 되었고, 파일이 전송되는 상황을 살펴보려고 합니다.
서버 쪽에서 먼저 시작하도록 하겠습니다!
서버에서는 어떤 프로그램이 작동을 하고 있습니다. 웹서버라고 가정을 해보죠~
통신을 위한 소캣이 열려있고, 소캣을 통해 통신을 합니다.
소캣: 네트워크 상에서 서로 다른 시스템 간에 통신을 가능하게 하는 엔드 포인트입니다. 소캣은 네트워크를 통해 데이터를 교환하기 위한 프로그래밍 인터페이스 (API)를 제공합니다. 통신 과정에서 하나의 소켓은 클라이언트 역할, 다른 하나는 서버의 역할을 하는 것이죠.
그런데 사실,,, 소캣의 본질은 파일입니다. 그리고 서버는 프로세스입니다.
프로세스가 파일에게 할 수 있는 동작은 기본적으로 Read, Write, eXecute (RWX)가 있지만, 소캣 통신에는 실행이라는 개념이 없으니 RW만 있겠네요. 소캣 통신에서는 읽거나 쓴다는 이야기를 다른 단어로 정의하는데, 바로 Receive와 Send입니다. 다시 말해, 서버가 소캣에다가 Iuput/Ouput (I/O)을 한다고 생각하면 됩니다.
저희가 전송하려는 파일은 어디 들어있을까요?
일반적으로 하드 디스크 안에 파일이 들어있습니다. (SSD도 상관없습니다.)
그리고 전송하려고 하는 파일은 A.bmp (비트맵 파일)이라고 해봅시다.
그리고 해당 파일은, 파일 시스템을 통해 관리가 됩니다.
하드디스크에는 디스크 드라이버가 존재하니, 하드 디스크 - 드라이버 - 파일 시스템을 거쳐 정보가 이동을 하겠죠?
드라이버: 컴퓨터의 하드웨어와 소프트웨어 사이에서 중재하는 프로그램으로, 드라이버는 운영 체제가 특정 하드웨어 장치를 인식하고, 그 장치와 상호작용할 수 있도록 도와주는 소프트웨어 인터페이스를 제공합니다.
여기서 굉장히 중요한 이야기가 있습니다.
서버를 어떤 언어로 개발을 하든, 서버에게는 메모리가 할당된다는 것입니다. (자바 애플리케이션도 마찬가지)
커널 영역을 제외한 나머지 공간에 메모리가 할당된다고 보면 됩니다. 애플리케이션을 실행하면, 운영 체제는 해당 프로세스를 위한 메모리 공간을 할당합니다. 이 공간에는 코드(프로그램 실행 코드), 데이터(전역 변수 등), 힙(동적으로 할당된 메모리), 스택(함수 호출과 지역 변수) 등이 포함됩니다. 이러한 메모리 영역은 프로세스의 실행에 필요한 모든 정보와 자원을 저장하는 데 사용됩니다.
저희는 전송하려고 하는 파일의 크기가 굉장히 크다고 가정을 할 거예요. 1.4MB 정도로 해보겠습니다.
그리고 파일을 읽는 메모리는 보통 개발자가 결정을 할 수 있는데요, 파일 시스템 입출력이나 네트워크 통신 중에 데이터를 일시적으로 저장하는 용도로 사용됩니다. 이 영역은 데이터를 임시로 캐싱하는 역할을 하고, 일반적으로는 1.4MB보다는 작습니다. 마찬가지로 운영체제에서 커널 영역을 제외한 나머지 영역에 존재합니다.
저희는 64KB 정도로 할당했다고 해볼게요.
파일에서 데이터를 읽어올 때, 파일 전체(1.4MB)를 한 번에 읽어올 수 없으니, 64KB씩 끊어서 가져와야 합니다.
때문에 메모리에는 64KB씩 끊겨서 쌓이게 되고, 서버는 64KB씩 파일로 끌어올려서 Read를 하는 것입니다.
저희가 작동시키는 웹 서버, 즉 프로세스(Server)는 TCP/IP 계층을 추상화한 것이기 때문에, 위와 같은 모양으로 생겼습니다. 그리고 소켓이 맞닿은 지점, 여기서 분해가 일어납니다.
TCP 쪽에서도 버퍼를 가지고 있습니다. 분해가 나는 이 지점입니다. (메모리=버퍼)
파일을 읽을 때 메모리에 할당된 버퍼를 버퍼 1, 소캣에서 분해가 일어날 때 존재하는 버퍼를 버퍼 2라고 해봅시다.
64KB가 버퍼 1에서 버퍼 2로 이동합니다. 이런 식의 입출력도 Buffered I/O입니다.
저희가 위에서 데이터를 전송할 때, 각 계층별로 데이터를 칭하는 용어가 다르다는 이야기를 했었죠!
애플리케이션의 데이터가 IP통신을 하기 위해 IP 계층으로 내려가는데, 이때 데이터(버퍼)는 분해가 되고, 그 조각이 세그먼트입니다.
보내려고 하는 파일을 직소 퍼즐로 표현해 보겠습니다. 지금 이 직소 퍼즐이 A.bmp (1.4MB) 파일입니다.
조각들 중, 64KB만큼만 메모리에 올릴 수 있습니다.
그럼 이 조각들이 버퍼에 가서 쌓입니다.
버퍼 1에서 버퍼 2로 똑같은 조각이 복사가 됩니다. 그리고 그것이 세그먼트가 되면서 각 조각조각마다 번호가 붙습니다.
네트워크 통신을 하기 위해서는 세그먼트하나가 패킷에 담깁니다.
패킷을 택배 박스로 비유해 보도록 하겠습니다. 저희는 택배 박스 안에 세그먼트(=직소퍼즐 하나)를 넣습니다. 택배 박스가 헤더라고 생각한다면.. 이 과정을 직렬화라고 볼 수 있겠죠?
이 패킷, 택배 하나는 인터넷을 타고 클라이언트 측으로 넘어가게 됩니다.
자... 여기까지가 서버 측에서의 이야기입니다.
택배 박스를 운송할 때는, 혼자 다니는 것이 아니라 택배 기사 아저씨에게 전달되고, 트럭을 타고 이동합니다.
패킷이 L2 수준(NIC)으로 내려올 때는 프레임이 됩니다.
패킷이 택배라면, 프레임은 트럭이라고 생각하면 됩니다. 헤더가 한 번 더 붙은 것이에요.
택배가 전달되는 동안 택배는 트럭을 몇 번 갈아탑니다.
패킷은 최종 목적지까지의 주소를 알 지는 못하지만, 라우팅 테이블에 의해 직후에 향해야 하는 라우터를 알 수 있어요. 그 라우터 위치를 담은 헤더로 감싸 다음 라우터로 향하게 하고, 해당 라우터에 도착하면 패킷을 벗긴 뒤, 다시 다음 라우터로 향하기 위한 새로운 헤더로 감쌉니다.
그렇게 최종적으로 클라이언트 PC에 도착합니다.
그럼 1번 직소퍼즐이 트럭을 타고, 클라이언트에게 무사히 전달이 되었다고 해보겠습니다!
클라이언트 측에서는 트럭을 받습니다. 출발 트럭이 A였다면 도착 트럭은 A가 아닌 B.. N번째 트럭이 도착하는 것입니다.
저희는 B라는 트럭이 도착했다고 하겠습니다.
이쪽에도 NIC이 있습니다. 마찬가지로 NIC을 작동시키는 디바이스 드라이버가 있을 거고, 그 위에는 TCP/IP 스택이 있을 것입니다. 그 위에도 마찬가지로 PC에 프로그램이 있을 것이고, 소켓을 타고 통신되었을 것입니다.
이 프로그램은 클라이언트의 역할을 하며, 마찬가지로 프로세스입니다.
소켓은 본질이 파일이라고 했죠? 클라이언트 측에도 마찬가지로 파일 입출력을 할 수 있는 버퍼가 있습니다. (File의 I/O 버퍼) 그리고 TCP도 버퍼를 갖고 있을 것입니다. (TCP 버퍼)
이 트럭 B(프레임)의 기사님께서 전달해 줄 택배(패킷)를 꺼내주시면, 해당 택배는 NIC -> 드라이버로 올라갈 때 역캡슐화 됩니다.
그럼 택배(패킷)에서 뿅 하고 튀어나오는 게 1번 직소퍼즐, 즉 세그먼트입니다. 헤더 역할을 하는 택배 박스를 벗고, 직렬화가 일어난 것이죠!
IP 수준에서 다뤄지는 데이터는 패킷, 이 패킷에서 껍데기를 까서 TCP에서 다뤄지는 데이터가 직소퍼즐 하나, 세그먼트입니다.
이 세그먼트들은 TCP 버퍼에 가서 붙습니다. 1, 2, 3 순차적으로 직소 퍼즐이 쌓입니다. 직소퍼즐이 1,2번까지 배송되었다고 하면, 세그먼트를 하나씩 총 2번 받은 것입니다.
그때는 클라이언트 쪽의 TCP가 서버의 TCP에게 잘 수신되었다는 것을 알려주어야 합니다. 그때 알리는 것이 ACK입니다. 1,2번 받았으면 ACK3을 쏩니다. 그럼 1,2를 잘 받았다는 뜻입니다!
그런데 서버 측에서는 1, 2번을 보냈다고 해서, 바로 3번을 보내는 게 아닙니다. wait를 합니다. 3번 ACK를 기다리는 것입니다. 서버는 3번 ACK를 받았을 때, 그럼 앞서 보낸 1,2가 잘 갔다고 이해합니다. 그러면 그제야 3번을 보냅니다.
이 과정을 3-way hand shake라 하는 것이며, 이 과정에서 속도 지연이 발생합니다. TCP가 UDP보다 느린 이유가 이런 이유 때문이라고 볼 수 있겠죠!
TCP 버퍼에 세그먼트를 채우고, 남는 사이즈를 윈도우 사이즈라고 합니다.
윈도우 사이즈는 "수신 측"에서 세그먼트가 날아오면 조립해서 집어넣을 수 있는 공간입니다.
ACK는 윈도우 사이즈를 포함하고 있습니다. 서버는 ack3을 받았을 때, 3번을 전송할지, 말지를 다시 결정합니다. 윈도우 사이즈를 봤을 때 해당 세그먼트가 들어갈 여유 공간이 있는지 확인하는 것입니다. 만약에 윈도우 사이즈가 충분하지 않다면 보내지 않습니다.
수신 측의 윈도우 사이즈가 보내려고 하는 maximun sement size(MSS) 보다 크다? 그럼 send, 그렇지 않다면 wait 합니다.
만약 TCP 버퍼에 쌓이는 세그먼트를 빨리 File I/O로 전달하지 않으면 어떻게 될까요?
클라이언트는 계속해서 서버 측의 데이터를 전송받지 못합니다.
클라이언트도 마찬가지로 프로세스가 소캣(파일)에게 할 수 있는 건 RW(Receive, Send) 이기 때문에,
클라이언트- 서버와 빠른 통신을 하기 위해 중요한 것은 클라이언트 측의 Receive의 속도라고 할 수 있습니다.
클라이언트 측에서 TCP 버퍼에서 FileIO 버퍼로 퍼올릴 때 Read 속도가 네트워크에서 수신하는 속도보다 빨라야 합니다. 만약 Read 속도가 네트워크 수신 속도보다 느리면... TCP 버퍼가 점점 쪼그라들고 여유가 사라지며, 수신 측의 Window Size, 여유 공간이 적어지면서 서버 측에서는 계속 wait가 걸리게 되는 것이랍니다!
윈도우 사이즈를 잘 체크하면 네트워크에서 애플리케이션의 문제를 해결할 수 있습니다. 만약 데이터 전송이 너무 느리다고 했을 때, 어플리케이션에서 문제를 분석하는 것이 아니라 네트워크에서 문제를 찾도록 합시다~!
추가로...
계층별 주요 프로토콜
| 어플리케이션 계층 | HTTP | 웹에서 데이터를 주고받는 서버-클라이언트 모델의 프로토콜 |
| FTP | 장치와 장치 간의 파일을 전송하는 데 사용되는 표준 통신 프로토콜 | |
| SSH | 한 컴퓨터에서 다른 컴퓨터로 보안성 있는 원격 로그인을 하기 위한 암호화 네트워크 프로토콜 | |
| SMTP | 전자 메일 전송을 위한 인터넷 표준 통신 프로토콜 | |
| DNS | 도메인 이름과 IP 주소를 매핑해주는 프로토콜 (사용자가 웹 브라우저에 도메인 이름 입력 -> 컴퓨터는 해당 서버의 IP 주소를 찾아 연결) | |
| 전송 계층 | TCP | 인터넷상에서 데이터를 메세지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜 |
| UDP | 데이터를 데이터그램 단위로 처리하는 프로토콜 | |
| 인터넷 계층 | IP | IP 주소를 이용하여 다른 지역 네트워크의 경로를 식별하는 프로토콜 (데이터 패킷을 라우팅하고, 주소를 지정함) |
| ARP | IP 주소로부터 MAC 주소를 구하는 IP와 MAC 주소의 다리 역할을 하는 프로토콜 | |
| ICMP | 데이터 전송 오류를 전달하는 프로토콜 | |
| 네트워크 계층 | Ethernet | MAC 주소를 이용하여 같은 지역 네트워크(LAN)의 장치를 식별하는 프로토콜 |
TCP의 이런 데이터 전속 기능을 바탕으로 웹 서버에서도 컨텐츠를 안전하게 주고 받게 되는 것입니다~!
HTTP는 이런 TCP 위에서 작동해요!
참고한 강의/책/글
이해하면 인생이 바뀌는 TCP 송수신 원리 강의
면접을 위한 CS 전공지식 노트
https://velog.io/@dyunge_100/Network-TCPIP-4%EA%B3%84%EC%B8%B5%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC
https://yozm.wishket.com/magazine/detail/1956/
https://yozm.wishket.com/magazine/detail/2005/
https://mangkyu.tistory.com/15