chapter2.txt

2장 : 통신 프로그램의 기초 지식
2.1 피해갈 수 없는 통신의 구조
[데이터는 어떻게 전달되는가]
데이터는 패킷이라는 그릇에 담겨서 운반된다.
패킷은 이후 케이블과 라우터를 거쳐서 상대방의 단말에 전달된다.
- 패킷에 포함된 정보들
 1) IP주소라는 수신인 정보를 넣어서 보낸다.(받는 단말의 주소)
 2) 포트 번호를 함께 보내는데 이는 어느 어플리케이션에 보낼 지에 대한 정보이다.(컴퓨터 내 어느 프로그램으로?)

[데이터가 사라진다?]
패킷이 유실되는 경우가 생길 수 있음.
- 처리량을 넘어선 데이터가 전달될 때(큐 오버플로 발생 : 패킷 드랍)
- 패킷 유실시 LAN 등에서 대체 경로를 찾는다. 대체 경로가 없다면 회선이 단절/통신 자체를 유지 불가능

그렇다면 패킷 유실 문제는 어떻게 해결 해야하는가?
이를 알기 위해서 프로토콜을 먼저 살펴보자.

2.2 프로토콜 이해하기
[안심할 수 있는 TCP]
TCP의 송수신 처리 과정
  A) 접속 처리
  B) 확인 응답(ACK) : 수신 버퍼의 크기가 담겨져 있음.
   * 수신버퍼의 크기가 보내고자 하는 데이터보다 크면 데이터 전송을 시작
  ---접속완료---
  A) 송신 요구 +데이터1
  B) 데이터1 수신 받음
  B) 확인 응답 +데이터1
  A) 확인 응답(ACK)

[TCP의 장점과 단점]
전송할 데이터가 크면 세그먼트라는 데이터로 작게 나눈다.
TCP는 APP에서 보낸 스트림 데이터를 버퍼에 저장, 데이터를 세그먼트로 나누어 송수신한다.
수신한 쪽은 세그먼트를 다시 결합해서 APP에 전달한다.

보낼 데이터가 작으면 각각의 작은 데이터를 TCP버퍼에 모아 시스템 최적 타이밍에 송신한다.
즉, TCP 버퍼가 꽉 차거나 규정 시간이 지나기 전에는 실제로 송신이 안되고, 지연되어 송신하게 되는 결과가 나타남.
수신하는 쪽에서는 결합한 데이터를 작은 데이터로 다시 나누어야 한다.
(큰 데이터와 작은 데이터에 대한 것은 TCP_BIG / TCP_SMALL.png 참고)

[속도가 빠른 UDP]
UDP는 패킷 로스, 확실히 받았는지 확인 등은 하지 않고 그냥 일방적으로 가져다주기만 한다.
 1. 데이터 송신 요청
 2. 데이터 전송 (끝)

[UDP의 장점과 단점]
순서를 보장, 전달을 보장하는 기능은 없다.
-> 순서가 뒤바뀌었을 경우 바로 잡아주는 기능을 추가해야할 수도 있다.
다만 빠르게 전달할 수 있음이 장점이다.

[온라인 게임에서 사용하는 프로토콜]
온라인 게임에서는 주로 UDP를 사용한다.
TCP의 재전송 기능이 온라인 게임에서는 악영향을 미치기 때문이다.

재전송 기능이 포함된 RUDP도 존재한다.
다만 SDK로 별도 제공되는 것을 구하거나 프로토콜 사양에 맞게 직접 구현해야 사용할 수 있다.
(표준으로 제공되는 프로토콜이 아니기 때문)

2.3 알아두면 좋은 기초 지식
[지연은 반드시 발생한다]
각 기기에서 데이터를 전달할 때 데이터가 이동하는 동안 발생하는 시간을 '지연 시간(레이턴시)'라고 한다.
RTT는 왕복 레이턴시, 즉 상대의 응답을 받을 때 까지 어느정도 시간이 걸렸는지를 의미한다.
(Latency.png 참고)
핵심은 레이턴시를 느낄 수 없게끔 만드는 것이다.

[통신량을 생각해보자]
데이터의 통신 속도에 대해서는 '통신 대역이 넓다/좁다'로 표현한다.
이와 관련된 단위로는 bps가 있다.(bit per second)
각 기기나 환경마다 회선 품질이 다르므로 항상 통신 대역을 신경써야 한다.
통신 레이어 마다 헤더가 추가되는 만큼 최대한 통신량은 가능한 작은 데이터로, 적은 횟수로 송신하는 것이 좋다.
한 패킷에 담을 수 없는 큰 데이터는 분할하고 합치는데 헤더가 늘어나 오버헤드로 작용할 수 있다.

이러한 통신량을 의식해서 설계해야한다.