상황) PC 한 대와 Server 한 대가 TCP/IP 통신(연결)을 하고 파일을 하나 다운받는 상황
- 연결: 3-way handshake
- 서버에서 파일을 가지고 있다가 클라이언트가 요청하면 송신함
Server
- server에서 어떤 프로그램이 작동하고 있음 (웹서버라고 생각해도 좋음)
- socket이 하나 열려 있고, 이것으로 클라이언트와 통신을 하고 있음
- socket의 본질은 file, server는 process
Process가 File에 할 수 있는 Operations
= RWX
- 소켓 통신에 실행의 개념은 없으니 읽던지 쓰던지
- R: 소켓통신에서 receive
- W: 소켓통신에서 send
= I/O
기본 구조
- 하드디스크 등 2차 메모리 안에 파일이 들어있다
- (가정)A.bmp라는 비트맵 File
- file system으로 관리됨
- 하드 디스크의 디바이스 드라이버가 존재
여기에 메모리를 할당(Buffer #1)
- 파일의 크기가 매우 크다고 가정(1.4MB)
- 메모리 크기는? 개발자가 결정, 중요한 것은 파일 크기로 다 잡지 않고 그보다 작게
- 예를 들어 64KB
- 1.4MB 전체를 한 번에 끌어 오는 것이 아니라 64KB만큼 끊어서 읽어 온다
- 파일에서부터 64KB만큼 끊어서 끌어 올려서 Read를 함
- Socket: TCP/IP를 추상화한 것
- Socket과 TCP가 맞닿은 지점에서 분해가 일어남
- TCP쪽에도 버퍼(메모리)가 있다 (Buffer #2)
- Buffer #1에서 Buffer #2로 copy가 일어남
- 이게 IP쪽으로 내려갈 때 잘개 쪼갠다 (Segment)
직소퍼즐에 비유하기
- 1.4MB짜리 직소퍼즐
- 퍼즐 4개가 64KB
- 이것이 메모리(Buffer #1)에 쌓임
- 똑같이 생긴 것이 Buffer #2에 copy됨
- 분해가 될 때 번호를 붙임
(실제로는 1, 2, 3, 4로 붙지 않고 더 크고 다른 규칙을 가진 수로 붙음)
- 이 중의 하나의 segment를 택배 박스에 넣음 (또 처리가 있긴 함)
- packet이란 택배 박스이다!
- 이 패킷이 PC쪽으로 넘어감
이동
- 택배를 택배기사에게 전달
- 택배 기사는 택배를 가지는 게 아님, 택배 기사는 무엇이 들었는지 관심 없음, 배송만 할 뿐
- 트럭에 실어 나름 (Frame: NIC 수준)
- 트럭의 목적지는 어디인가?
- 택배 박스는 한 트럭으로 처음부터 끝까지 가는 것이 아님
- 트럭을 갈아탐
- Packet은 논리적으로 Endpoint 부터 Endpoint까지 가지만
- 그게 Frame화될 때는 Frame이 생겼다 사라졌다함
PC
- 이 PC는 네트워크에 연결되어 있다 가정 (네트워크 인터페이스가 있음)
- 트럭 B가 도착
- 클라이언트 Process
- Socket의 본질은 File, 이 파일에 연결된 Buffer 하나 (File I/O Buffer)
- TCP도 Buffer를 가짐
- 택배기사가 트럭에서 택배를 꺼내고
- Frame을 타고 올라가다가 IP를 만나면 Frame은 사라짐
- Decapsulation
- 박스를 뜯는 것
- 박스 안에 있는 segment가 튀어나옴
- IP수준에서 다루는 데이터는 Packet, 여기서 껍데기를 까서 TCP수준에서 나오는 것이 Segment
- 1번 segment가 TCP Buffer에 가서 붙음
- 2번도 이 과정을 거쳐 TCP Buffer에 들어감
- Segment가 2개정도 오면 PC
- PC가 잘 수신했다는 걸 Server에 알림
- 번호를 알려주는데 3번이라고 함 = 1, 2번 잘 받았으니 3번을 보내라!
- 이때 서버는
- 1번을 보내고 2번을 보낸 뒤 바로 3번을 보내는 게 아니라 Wait함
- ACK를 기다림
- 기다리던 ACK가 도착하면 1, 2번이 PC에 잘 갔구나 생각
- ACK를 받고 나서 3번을 보냄
- 하지만 이 기다림 때문에 속도 지연 발생
- TCP/IP공부할 때 TCP가 UDP보다 느리다고 배울 것, 이 Wait때문! (+a)
- 수신측에서 Segment가 날라오면 조립해서 넣어둘 수 있는 공간
- window size는 정해져있다
- Ack을 보낼 때 include window size (윈도우 사이즈를 포함하고 있다)
- 서버측(송신측)에선 3번을 전송해야하는데 전송 할까말까를 결정해야함
- ACK 내의 정보를 보고 3번을 보낼 만큼 충분한 공간이 있으면 보내고
- 공간이 부족하다면 Wait(기다림)
- 느리다고 투정하는 건 client인데 왜 느린지 생각해보면 server가 느린게 아니고 수신하는 client에 자리가 없음
- TCP buffer에 들어있던 애들을 빨리 퍼올려서 FIle I/O Buffer로 올려야해
- 읽는 receive 속도를 따져봐야함
- 이 프로세스를 개발했는데 Read속도(퍼올릴 때 속도)가 Network에서 수신하는 속도(채워지는 속도)보다 무조건 빨라야한다
- 느려지면 window size 여유가 사라짐
- 서버에서 wait을 함
- 처리 지연에 대한 문제: Window size를 잘 체크하면 어플리케이션에서 문제를 찾을 수 있다 (다른 원인도 많겠지만)
- 일단 read speed를 올려서 일단 읽은 다음에 처리를 하든 하면 됨
출처: https://youtu.be/K9L9YZhEjC0?si=zz_jx78wNMw_OAhk
'백엔드 > 네트워크' 카테고리의 다른 글
| [네트워크기초이론]#29. IP주소의 종류와 특징 (1) | 2023.10.04 |
|---|---|
| [네트워크기초이론]#28. Unicast, Broadcast, Multicast (1) | 2023.10.04 |
| [네트워크기초이론]#21. Proxy의 활용 첫 번째. '우회' (1) | 2023.10.03 |
| [네트워크기초이론]#20. Proxy의 구조와 작동원리 (0) | 2023.10.02 |
| [네트워크기초이론]#19. Inline 구조와 Out of path 구조 (0) | 2023.09.27 |