Network 기본 개념 - TCP

3 minute read

TCP

어플리케이션 계층
- Baundary delivery - 해당 데이터에 대하여 명확하게 하나의 데이터로 보낸다.
전송 계층
- Stream of byte - 해당 데이터에 대하여 전혀 알지 못하고 특정 크기로 데이터를 짜르며 모든 데이터를 byte로만 판단해서 밑에 계층으로 내려 보낸다.
- 따라서 반드시 순서를 보장해서 데이터를 읽어서 위로 보내야된다.
데이터를 받고 그것에 대한 ACK 패킷은 selective가 아닌 cumulative이다.
- 이것은 내가 다음으로 받은 데이터의 시작 byte의 의미로 받아들여도 되는데 (혹은 시퀀스 넘버)
- cumulative는 selective보다 에러를 빠르게 찾을 수 있다. 하지만 cumulative도 약간의 문제는 있다. 연속적으로 많은 패킷을 손실했을 경우 그것에 대하여 빠르게 대처하기 어렵다.
보내는 패킷의 이상을 체크하기 위해 “체크썸”을 활용함

연결을 원하는 네트워크와 혹은 서버와 같은 곳과 서로 통신 가능한지에 대하여 확인하는 과정이라고 할 수 있다.

한 쪽에서 연결을 종료하고 싶을 때 안정적으로 연결을 끊기 위해서 진행되는 과정

TIME-WAIT을 하는 이유
1. 내가 보낸 ACK 패킷이 제대로 도착하지 않아서 받는 쪽에서 ACK 패킷을 계속 기달릴 수도 있음
2. 우연치 않게 연결이 끝났는데 바로 똑같은 port로 연결이 다시 진행된 경우에, 이전에 연결 해제를 하기 위한 FIN 패킷을 받아 원하지 않는 종료가 될 수 있는 문제를 없음 → Port 번호를 일정 시간정도 점거하는 역할

Stop and Wait
- 하나의 패킷을 보내고 그 데이터가 도착해야지만 다음 데이터를 보내는 방법
- 신뢰성을 확실히 보장
- 하지만 속도가 매우 느림
슬라이딩 윈도우
- 특정 사이즈만큼 데이터를 모두 보내는 방식
- 제대로 도착하지 않은 데이터에 대해서는 상대방의 응답에 대하여 대응
- 이전 방식보다 훨씬 빠름
Window size : 특정 패킷에 대하여 ACK이 올때까지 보낼 수 있는 데이터의 양

송신 측 문제
- 보내는 데이터가 굉장히 작은데 지속적으로 보내느라 실제 보내는 데이터보다 헤더가 더 큰 현상
- Nagle 알고리즘 → 처음에는 데이터를 보내는데 그 보낸 패킷이 돌아올 때 까지나 MSS 까지 패킷이 만들어지는 것을 기달리고 보내는 알고리즘
수신 측 문제
- 실제로 데이터를 처리하는 속도가 느려서 받을 수 있는 데이터가 굉장히 적어 송신측에서는 적은 데이터만 보낼 수 밖에 없는 상황이 되는 문제
- rwnd를 0으로 해서 ACK을 보내거나
- ACK 패킷을 보내지 않는 경우로 문제 해결

발생 원인
- 특정 라우터에서 자신이 수용할 수 있는 것보다 더 많은 패킷이 도착하는 경우 그것에 대하여 병목 현상과 시간이 지남에 따라 손실되는 패킷들이 발생하게 된다.
- 손실된 패킷으로 인해 또 네트워크에 손실 패킷을 보내고 그로 인해서 혼잡은 심해진다.
연산
- Slow start: 해당 데이터를 보내고 그것에 대하여 정상적으로 돌아오는 경우 2배씩 증가해서 데이터를 보냄
  - ⇒ 쓰레쉬 홀더라는 것이 존재하는 거기까지만 2배까지 증가함
- Additive increase: 데이터가 돌아올때마다 (RTT) 보내는 패킷에 양을 1씩 증가시킴
혼잡이 발생했다는 증거
- 타임 아웃: 보내는 데이터의 양을 1로 줄이고 마지막 보냈던 양의 절반을 쓰레쉬홀더로 수정한다. 그 후 다시 slow start
- 3-dup ack: 보내는 양을 절반, 쓰레쉬홀더도 절반. Additive increase를 진행한다.