TCP/IP 쉽게, 더 쉽게

 

p.11
회선 교환 방식과 패킷 교환 방식
아날로그 방식의 유선 전화나 3G 방식의 휴대전화는 회선 교환 방식을 사용한다.
회선 교환 방식은 통신하려는 양측을 연결하기 위해 하나의 통신 경로를 점유한 후 통신하는 방식이라서 기본적으로 일대일 통신만 할 수 있다.
패킷 교환 방식은 주고받을 데이터를 작게 쪼갠 후 다른 데이터의 조각들과 통신 경로를 공유하며 전송하는 방식이라서 여러 상대와 통신할 때 효과적이다.

 

p.54
음성이나 동영상 데이터는 메일과 같은 테스트 형태의 정보에 비해 상대적으로 데이터 용량이 크기 때문에 통신의 신뢰성보다는 전송 속도에 우선하는 UDP를 사용하고, 전송 시에는 데이터를 압축하되 수신된 정보를 바로 재생할 수 있는 스트리밍 기술을 사용한다. 전송 중에 일부 데이터가 누락되더라도 신경 쓰지 않는다.

데이터를 빠르게 전송하기 위해서는 UDP 프로토콜을 사용하고, 데이터를 정확하게 전송하기 위해서는 TCP 프로토콜을 사용한다.

 

p.55
동영상 공유 서비스가 사용하는 프로토콜
음성이나 동영상을 처리하는 프로토콜은 아직 널리 보편화된 것이 아니기 때문에 일부 네트워크 환경에서는 통신이 거부되는 경우가 종종 발생할 수 있다.
그래서 유튜브와 같은 동영상 공유 서비스에서는 동영상 프로토콜에서 사용할 데이터를 HTTP 메시지 안에 채워 넣는 기술을 사용하고 있다. HTTP라면 차단되는 경우가 거의 없으므로 더 많은 환경에서 차단 없이 동영상을 서비스할 수 있다.

HLS(HTTP Live Streaming)프로토콜을 사용한다.
RTP/RTSP 대신 HTTP를 사용하는 이유
- 방화벽 친화적 : HTTP(80/443)는 거의 모든 네트워크에서 허용한다.
- CDN 활용 가능 : 기존 HTTP 인프라와 캐싱 시스템 활용할 수 있다.
- 웹표준 호환 : 별도 플러그인 없이 HTML5에서 직접 재생할 수 있다.

HLS를 통해서 동영상을 브라우저에 전달하는 원리

[동영상 사전 준비]
- 원본 영상을 다중 해상도로 인코딩한다.
- 영상을 세그먼트로 분할한다. (chunk)

[브라우저에서 동영상 플레이]
- 브라우저에서 manifest 파싱 (품질별 플레이리스트 정보 확인)
- 네트워크 상황 분석 후 품질 선택
- 해당 품질 Playlist 요청 (GET /video/720p/playlist.m3u8)
- 세그먼트 병렬 다운로드
    - GET /video/720p/segment_001.ts
    - GET /video/720p/segment_002.ts
    - GET /video/720p/segment_003.ts
- 영상 재생
- 재생 중 지속적인 네트워크 모니터링

 

p.60
컴퓨터 안의 프로그램까지 데이터가 전달되는 모습은 쉽게 상상하기 어려워 막연하게 생각하는 독자들이 많을 것이다. 이렇게 컴퓨터 안까지 들어온 데이터를 각 프로그램까지 전달하는 것이 바로 트랜스포트(TCP, UDP) 계층이다.

 

p.65
포트 번호의 범위
포트 번호는 0~65535까지 사용할 수 있고, 웰 노운 포트, 레지스터드 포트, 다이나믹 포트의 세 종류로 구분된다.
이 중 웰 노운 포트는 애플리케이션 계층에서 많이 사용되는 대표적인 프로토콜의 수신 포트들이다.
웰 노운 포트 : 0~1023
레지스터드 포트 : 1024~49151
다이나믹 포트 : 49152~65535
클라이언트가 사용하는 포트 번호는 그때그때 다르다.
클라이언트가 사용하는 포트 번호는 다이나믹 포트 번호 대역에서 자동으로 할당되기 때문에 어떤 번호가 사용될지는 미리 알 수 없다.

클라이언트 애플리케이션이 connect() 호출 시 OS가 사용 가능한 동적 포트를 할당한다.

 

p.68
TCP가 하는 일
TCP는 트랜스포트 계층의 프로토콜의 하나로서 웹이나 이메일, FTP와 같이 정확한 데이터 전달이 필요한 통신에 사용된다.
TCP는 데이터 전송에 신뢰성을 더하기 위해 세그먼트라는 단위로 분할하고, 전송 속도를 조정하며, 데이터가 제대로 전달되지 않았을 경우 재전송을 하게 된다.

• 전송 속도 조절하기
• 데이터 재전송하기

 

p.70
통신 개시부터 통신 종료까지의 흐름
TCP 통신은 커넥션 연결에서 시작한다. 커넥션을 맺는 과정은 3단계로 진행되기 때문에 이것을 3방향 핸드쉐이크라고 부른다.

• 커넥션 연결
  • SYN --->
  • <--- SYN + ACK
  • ACK --->
• 커넥션 연결 끊기
  • FIN --->
  • <--- ACK
  • <--- FIN
  • ACK --->일련번호와 최대 세그먼트 크기를 사전에 조율한다.커넥션을 맺을 때 송신 측과 수신 측은 원활한 통신을 위해 사전에 일련번호와 최대 세그먼트 크기(MSS)를 서로 협의하고 조율하는 과정을 거치게 된다.
    커넥션을 맺는 과정에서 일련번호는 1씩 증가하는데, 데이터를 전송할 때는 여기에 전송한 데이터의 바이트 수만큼 더 더해진다. 또한, 데이터를 수신한 후에는 수신한 데이터의 바이트 수 만큼을 확인 응답 번호에 더하기 때문에 일련번호와 확인 응답 번호를 확인하면 몇 바이트의 데이터를 주고받았는지 알 수 있다.

[MSS 결정 과정]
TCP 3-way 핸드쉐이킹 과정에서 MSS 값을 서로 주고 받는다. 이때 양쪽이 제시한 MSS 중 작은 값을 채택하여 사용한다.
MSS 협의 과정이 필요한 이유는 상대방이 처리할 수 있는 최대 세그먼트 크기를 알기 위해서이다. 서로 감당 가능한 최대 데이터 크기를 확인하고, 그 크기 이내로만 세그먼트를 보낸다.

[MSS 기본값 계산]
MSS = MTU - IP Header - TCP Header
MTU: 1500 bytes
IP Header: 20 bytes
TCP Header: 20 bytes
-------------------------
MSS = 1460 bytes

SEQ(Sequence Number) : 내가 보낼 데이터의 첫 번째 바이트 번호
ACK(Acknowledgment Number) : 네가 다음에 보내야 하는 데이터의 첫 번째 바이트 번호

송신 실패 여부를 판단한다.

패킷 일부가 제대로 전달되지 않거나 패킷 자체는 전달되었더라도 응답 패킷이 전달되지 않는 경우가 발생할 수 있다. 송신 측에서는 일정 시간이 지난 후에도 수신 측으로부터 응답이 오지 않을 경우 송신 실패로 간주하고 최근에 정상적으로 응답을 받은 후부터 데이터를 재전송한다.

한번에 받을 수 있는 데이터 크기를 통보한다.

연속해서 몰아 보내는 데이터의 양이 너무 많으면 수신 측이 제때 처리하지 못할 수 있다. 그래서 수신 측은 수신한 데이터를 일시적으로 보관할 수 있는 버퍼라는 저장 영역을 가지고 있다.
수신 측은 TCP 헤더의 윈도우 사이즈에 이 버퍼의 크기를 설정하고 송신 측에 통보함으로써 어느 정도의 크기까지 받아 낼 수 있는지를 알려주게 된다.

 

p.77
UDP를 애플리케이션 계층으로 둘러싼다.
실시간 처리가 필요한 온라인 게임에서는 전송 속도가 우선인 UDP를 사용하긴 하지만, 데이터 전송의 신뢰성 역시 속도에 못지않게 중요하다. 이런 경우에는 애플리케이션 계층에서 흐름 제어나 혼잡 제어를 구현해서 부족한 신뢰성을 보완하게 된다.
TCP 처럼 데이터 전송의 신뢰성을 높이면서도 효율적인 처리로 속도 저하가 크지 않게 만들어 줍니다.

UPD 위에서 동작하는 신뢰성 프로토콜에는 RTP, QUIC 등이 있다.

RTP(Real-time Transport Protocol)은 실시간 오디오/비디오를 전송한다. VoIP, WebRTC 등이 이에 해당한다.
QUIC(Quick UDP Internet Connections)은 HTTP/3 기반으로 동작하며 TCP 수준의 통신 신뢰성을 보장한다. 재전송 처리, 흐름 제어, 혼잡 제어를 포함한다.

 

p.79
netstat 명령
ESTABLISHED : TCP로 접속이 맺어져 통신이 이루어지고 있다.
LISTEN : 서버가 수신 대기 상태다. -a 옵션을 통해 확인할 수 있다.
TIME_WAIT : 접속을 종료하려는 중이다.

윈도우에서 netstat -nao 명령어를 실행해 보면 CLOSE_WAIT도 출력된다.
CLOSE_WAIT은 원격에서 FIN 패킷을 보내고, 로컬에서 ACK를 응답했지만 아직 로컬의 FIN을 원격지로 보내지 않은 상태를 의미한다.

Client (내 애플리케이션)                Server (상대방)
        |                                     |
        | <----------- FIN -------------------|   (서버가 먼저 연결 종료 요청)
        |                                     |
        | ----------- ACK ------------------->|   (Client: 알았다 응답)
        |                                     |
        |   (이 시점에 Client 상태: CLOSE_WAIT) |
        |                                     |
        | ----------- FIN ------------------->|   (애플리케이션이 close() 호출 시)
        | <----------- ACK -------------------|   (서버: 확인 응답)
        |                                     |
     [Closed]                              [Closed]

 

p.87
IP 패킷에도 유통기한이 있다.
수신지로 지정된 컴퓨터가 실제로는 존재하지 않거나 통신 경로를 찾지 못해 패킷이 제대로 전달되지 않는 경우가 종종 발생할 수 있다. 이렇게 패킷이 목적지를 찾지 못해 네트워크 안을 계속 떠돌게 되면 네트워크가 혼잡해질 수 있는데, 이러한 문제를 방지하기 위해 IPv4 헤더에는 생존 시간(TTL) 정보를 설정할 수 있게 되어 있고, 만약 생존 기간을 초과한 패킷이 네트워크상에서 발견되면 그 패킷을 소멸시키도록 규정하고 있다.

 

p.88
한 번에 전송할 수 있는 데이터 크기를 MTU(Maximum Transmission Unit)라고 하고, 이 값은 통신 경로의 상태에 따라 달라진다. 예를 들어, 경로 상태가 좋지 않으면 이 값이 줄어들게 되는데, 라우터에는 이 MTU 값에 따라 패킷을 분할해서 전송하는 기능이 구현되어 있다. 다만, 라우터의 작업 부하가 높아지거나 분할된 패킷 중의 일부가 유실되면 복원이 어려워지는 단점이 있다.

 

p.90
IP 어드레스는 네트워크 부와 호스트 부로 구성된다. 여기서 말하는 호스트는 네트워크에 연결된 컴퓨터나 네트워크 장비를 의미한다.
네트워크라는 용어는 여러 컴퓨터가 연결되어 데이터를 주고받을 수 있는 것을 의미하는 과의의 개념이다. 그래서 가정이나 사무실 내의 LAN은 물로 인터넷 전체도 네트워크에 해당한다.

192.168.1.100
--------- ---
네트워크 부 호스트 부

 

p.91
클래스 A의 어드레스는 한 개의 네트워크당 약 1677만 대의 호스트의 어드레스를 할당할 수 있다. 하지만 실제로 그렇게 많은 호스트를 하나의 네트워크에 연결하는 경우는 거의 없기 때문에 많은 수의 어드레스가 사용되지 않고 낭비된다.
좀 더 효율적으로 어드레스를 할당할 방법이 없을까?
어드레스 클래스를 사용한 네트워크를 좀 더 세분화할 수 있는데 이때 사용하는 것이 서브넷 마스크입니다.

 

적용할 점

• TCP MSS 단편화를 직접 관찰할 수 있는 환경 셋팅 후 실험해 보기

 

느낀점

도서관에서 우연하게 발견한 책이다.
TCP/IP 프로토콜 동작 원리를 그림으로 잘 표현해주고 있어서 빌려보았다. (책을 많이 읽었어도 그림이 있으면 이해하기 편해서 좋다.)
읽으면서 잊고 있었던 TCP 프로토콜 스펙을 다시금 상기 시킬 수 있었다.
10년이 훌쩍 지난 예전에 TCP 서버와 클라이언트를 만들었던 경험이 새록새록 떠오른다.
TCP 프로토콜을 사용해서 처음으로 개발한 프로젝트가 SKT 날씨 정보 서버와의 연동이었다. 날씨 정보를 얻기 위해서 TCP Client 를 개발해야 했다.
그때 당시에는 HTTP를 주로 사용했기에 TCP를 사용하여 애플리케이션을 만드는 게 쉽지 않았다. 다행히 Netty 프레임워크의 전신인 MINA 프레임워크가 있었기에 쉽게 개발할 수 있었던 기억이 있다. (MINA를 만들어 주신 이희승님 감사합니다.)
TCP 서버를 만들었을 때에는 광고 플랫폼 타겟팅 서버를 만들때였다. 이 서버를 왜 TCP 서버로 만들었냐? 사연이 많다.
전송 서버와 타겟팅 서버가 서로 연동을 해야 하는데 전송 서버는 C 언어로 만들어졌다. 그때 당시 C 언어로 만들어진 서버는 HTTP 통신 보다 TCP 통신이 주를 이루었다.
HTTP 통신으로 연동하면 네트워크 오버헤드가 많다고 설득 당해 TCP로 만든 기억이 있다. (짬밥에 밀렸......)
책을 읽는 동안 옛 추억이 새록새록 떠올라 더욱 즐겁게 읽을 수 있었다.