TCP 송수신 원리 - 널널한 개발자 TV

rbw·2023년 1월 6일
1

TIL

목록 보기
67/97

참조

https://www.youtube.com/watch?v=K9L9YZhEjC0

위 영상을 보고 정리한 글


상황

어떤 클라이언트(PC)가 서버 한 대와 TCP/IP 통신을 한다는 가정, 연결은 되어있고 파일을 하나 다운로드를 받는 상황

서버쪽 상황

79% 뒤에 있는건 NIC라고 적힌검다. 영상 도중도중 캡처라 사진이 난잡함다,, 밑에서 설명 보면서 사진 보면 더 조을듯 함

서버에서는, 어떤 서버 프로그램이 작동하고이씀. 웹 서버라고 생각해도 좋다. 중요한건 소켓이 하나 열려있음. 이걸로 통신을 하고 있음. 소켓의 본질은 파일임. 서버는 기본적으로 프로세스이고, 따라서 프로세스(서버)가 파일(소켓)에 할 수 있는 작업은 RW(Read Write)가 있음

여기서 리드 라이트는 소켓 통신의 경우에는 좀 다르게 부른다고 함. 리시브(Receive), 샌드(Send)라고 부릅니다. 서버 프로세스가 소켓에대고 I/O를 한다고 보면 됨

HDD 이런 2차 메모리안에 파일이 들어있슴다. 이 파일이라고 하는 것이, (A.bmp 같이 비트맵 파일이라고 가정을 하였음)이는 파일 시스템으로 관리가 될 것이고, 드라이버(하드디스크의 디바이스에)가 존재합니다. 그래서 하드디스크에서 <-> 드라이버 <-> 파일 시스템 으로 정보를 주거니 받거니 할 것입니다.

여기서 중요한 것은 서버를 무슨 언어로 개발을 하든, 어떤 구조로 하냐면 서버 쪽에 메모리를 할당한다고함. 메모리에 사이즈를 얼마로 잡을지는 개발자의 몫임 .

보통 이 서버에 할당한 메모리는 파일의 용량 (파일의 크기가 좀 크다고 가정을하고, 1.4MB 정도)보다 작다고 하심 64KB로 잡았다고 가정을함.

파일에서 데이터를 읽어올 때 한 번에 1.4MB를 읽는게 아니라 64KB로 끊어 읽어서 들고온다고 함. 따라서 일단 64KB를 읽어와서 메모리에 적재를 함. 이 과정을 리드라고 함 . 파일로 부터 메모리에 적재까지~~

자바든 cpp든 여기서 소켓이란건 TCP/IP를 추상화 한 것. 유저 모드 커널모드 왼쪽편 그림 참조.

소켓이 맞닿은 지점에서 분해가 일어난다고 함. 이 분해가 일어나는 지점, TCP 쪽에도 버퍼(얘도 결국 메모리)가 존재함. 여기서의 버퍼를 2번이라고 함. 서버 옆 메모리가 버퍼 1번. 버퍼 1번에서 2번으로 카피가 일어날 것임.

이러한 입출력 방식을 Buffered I/O라고 부름.

이제 TCP 쪽에서 IP 쪽으로 내려갈때 일어나는 일은 퍼즐에 비유하셨음. 64KB라면 퍼즐 한 4개정도라고 치고, 이를 메모리(버퍼 1번)에 적재함. 이를 세그먼트로 간다 라는 의미가, 버퍼 2번에 복사한 친구들에 퍼즐 하나하나에 번호를 붙임니다. 실제 번호는 더 크고 규칙도 다르고 그렇다고 함

패킷이란 무엇이냐 ~? 라고 물어보면, 택배박스하고 비슷하다고 생각하면댐 박스안에 1번 세그먼트(퍼즐조각)을 넣고 PC 쪽으로 날라간다고 생각하면 댐. 따라서 패킷 하나가 인터넷쪽으로 쭉 간다고 생각하면 된다.

그런데 택배 박스가 지 혼자 가는것은 아니지않슴니가? 택배 기사 아저씨한테 전달을 해야함. 하지만 이게 택배 기사 아저씨가 가진다는 의미가아님. 기사 아저씨는 트럭을 타고 왔을거고, 그 안에 박스를 넣을 거임.

패킷이 NIC 쪽으로 내려올 때, L2 수준으로 내려오면 프레임이라고 부른다네요.

트럭은 프레임이라고 생각하면된다. 택배는 트럭을 몇 번 갈아탑니다. 패킷 자체는 엔드포인트에서 엔드포인트로 가지만, 프레임으로 되었을 때는 생겼다 사라졌다의 반복이기 때문임

클라이언트 쪽 상황

이제 트럭이 왔을 때 부터의 흐름을 설명 하게씀다.(사진 아래쪽 B 트럭 부터 스타트~ PC의 관점 !) 위 사진의 트럭(B)은 이전 사진에 트럭(A)과는 다름니다.

이 PC도, PC용 프로세스가 있을것임. 이걸 추상화 시킨 소켓을 타고 통신을 했을검니다. 이 소켓은 결국 파일임다. 위에서 설명했듯이? 얘도 버퍼를 들고 있슴니다. (File I/O Buffer) TCP도, 버퍼를 가지고 있슴니다. (TCP Buffer, 얘가 TCP 공부할 때 윈도우 사이즈라고하네요 수신 측에서 세그먼트가 날라오면 조립해서 집어 넣을 수 있는 공간)

이제 이 트럭에서 택배 기사 아저씨가 택배를 끄집어내서 나한테 주겠져 여기서 박스를 언박싱합니다(디캡슐레이션, decapsulation). IP 레이어를 만나면 프레임은 없어집니다. 여기서 튀어나온건 세그먼트입니다.

IP 수준에서는 패킷이고, TCP 수준에서는 패킷에서 껍데기를 까서 세그먼트가 나옴. 따라서 TCP 버퍼에 세그먼트가 하나 적재가 됩니다.

다 그렇지는 않지만, 보통 이제 세그먼트 2개정도를 받아서 잘 수신 했음을 서버에 알리는데 이를 ACK(acknowledge character)라고 합니다. 1번 2번을 받았으면 이제 번호를 알려주는데 이 경우는 3번이라고 알려줍니다. 3번 보내라는 뜻 ~

서버 쪽에서는 1번 2번을 보냈다면, 다음 행동은 'ACK 3번' 을 기다립니다 (wait). 이 기다림 때문에 속도 지연이 발생합니다. 이 기다림 때문에 TCP가 UDP보다 느린 것임

또 ACK 안에 윈도우 사이즈를 포함하고 있습니다 ! ACK가 오고 3번을 전송해야하는데, 사이즈를 보고 판별을 합니다. 보낼지 말지를, 사이즈가 부족하면 안 보냅니다. 수신측의 윈도우 사이즈가 보내는 세그먼트에 비해 작다면 또 Wait ~

중요한건 TCP 버퍼에 있는 친구들을 빨리 조립해서 파일 버퍼에 올려야 지연이 덜 발생한다 ! 리시브 속도를 따져야 합니다. TCP 버퍼에서 조립해서 파일 버퍼로 올라가는 속도가 네트워크에서 수신하는 속도보다 무조건 빨라야합니다

그래서 속도 지연의 원인을 클라이언트에서도 체크를 해야한다 ~


유튭 영상보면서 고대로 적어서 난잡하긴함다,,, 매우 설명을 잘해주셔서 영상 보시는거 추천 !

profile
hi there 👋

0개의 댓글