TCP #2 TCP 플래그, 시퀀스 넘버와 누적 ACK

Source Port # 16 bits								Dest Port # 16bits
Sequence Numner 32bits
Acknowledgrment Number 32bits
Head len 4bits	now used 6bits	U	A	P	R	S	F	Receive Window 16 bits
Checksum 16bits								Urg Data Pointer 16bits
Options (variable length)
Application Data (variable length)

 

포트 번호가 있으니 이걸로 멀티플렉싱, 디멀티플렉싱

 

- Sequence Number:

시작 지점은 OS가 부여.

악의적으로 캐치 시 도용이 가능해기 때문에 처음엔 랜덤으로 부여됨

그 다음부터는 보내는 데이터의 양에 따라 달라짐.

100번으로 보내고 데이터 양이 50바이트이면 그 다음 시퀀스 넘버는 150번

 

- Acknowledgrment Number: 정확히는 다음에 받아야 할 번호를 가짐

이전 거 잘 받았으니 다음에 받을 거를 요청하는 의미

 

- Head length

UDP는 헤더 길이가 8바이트 고정

TCP는 기본 20바이트고 옵션이 있어서 더 길어질 수 있음

 

- 플래그 (각각 1비트)

U: URG. 급한 데이터라는 뜻 (잘 안씀)

A: ACK. 활성화 시(1) 아크 넘버가 유의미하다는 뜻

P: PSH. 수신 측은 버퍼에 쌓지 말고 바로 프로세스로 올리라는 뜻 (잘 안씀)

R: RST. 핸드셰이킹부터 다시 하지는 뜻

S: SYN. 처음 핸드셰이킹할 때 켜는 플래그

F: FIN. 끝낼 때 켜는 플래그

 

* 추가 제어 비트

ECE (Explicit Congestion notification Echo) : IP 헤더의 ECN과 연동, 혼잡 제어

CWR (Congestion Window Reduced) : ECE를 확인하여 윈도우 크기를 줄임

 

- Checksum

데이터 왜곡 확인 용

 

- Urgent Pointer

U 플래그가 켜졌을 때 급한 데이터가 어디 있는지 가리킴

근데 잘 안씀

---

시퀀스 넘버 = 보내질 응용계층 데이터의 첫 바이트 주소

아크 = 다음 받고자 하는 순차 번호

 

호스트 둘이 통신을 한다고 가정

수신 시 받은 아크 넘버는 송신 시 보낼 시퀀스 넘버가 될 것

송신 시 보낼 아크 넘버는 수신 시 받은 시퀀스 넘버 + 데이터 크기가 될 것

---

- TCP 타이머

너무 짧으면 : 재전송이 많앙짐

너무 길면 : 손실에 대해 대처가 잘 안됨

 

RTT보다 좀 더 길게 하면 되는데, RTT는 가변적임.

예측이 필요

 

EstimatedRTT = (1-a) * EstimatedRTT + a*SampleRTT

* a = 0.125

 

예측값과 실제값에 가중치를 두고 더해서 다음 예측

 

TimeInterval = EstimatedRTT + 4*DevRTT

 

RTT보다 좀 더 커야 하기 때문에 safety margin을 두는 것

---

송신자는 응용 계층의 데이터를 받으면

- 세그먼트를 만들고 시퀀스 번호 부여

- 보내고 나서 타이머 설정

- 타이머가 종료되면 재전송 및 타이머 설정

- 아크를 받으면 윈도우에 아크 번호 재설정(슬라이드 윈도우), 아크를 받지 않은 세그먼트들이 있으면 타이머 시작

 

수신자는 송신자에게 데이터를 받으면

- 비트 에러 체크.. NAK ** 실제는 NAK 안보내고 송신자가 알아서 보내도록 함

- 시퀀스 번호를 검사하여 문제가 없으면 누적 ACK, 중복되면 버림

- 실제 TCP는 GBN과 Selective 방식 절충

---

재전송 시나리오

아크가 오지 않으면 송신자는 다시 보낼 것임

타이머가 적절한 경우..

중간에 안 온 아크가 있어도,

누적 아크 방식은 문제 없이 받은 패킷에 대한 가장 최신 아크를 주기 때문에

아크를 안받았어도 잘 받았다고 해석이 가능

-> 누적 아크의 장점

---

TCP fast retransmit (GBN) (빠른 재전송)

안 온 패킷이 있으면 수신자는 그 패킷에 대한 아크를 계속 보내는데

중복 요청이 3번 발생할 시, 타임아웃과 관계 없이 바로 해당 시퀀스 넘버를 가지는 패킷을 전송

---

흐름제어 (Flow Control)

받는 쪽의 응용 계층에서 처리가 느려서 버퍼가 감당을 못하면 송신자는 늦게 보내줘야 함

- RcvBuffer : 버퍼 사이즈 (기본 4096 바이트, OS가 조정 가능)

- rwnd : 쓸 수 있는 버퍼 공간

 

수신측은 rwnd 정보를 보내줘야 송신 측에서 속도 조절이 가능함

송신자는 ACK를 받지 않은 패킷의 수를 수신자의 rwnd 값보다 작게 해야 함

---

핸드셰이킹

연결 설정 - 쓰리 웨이 핸드셰이킹

- 서버 패시브 오픈 : TCP에 연결 받을 준비 됐다고 알림

- 클라이언트 액티브 오픈 : 특정 서버와 연결이 필요하다고 TCP에 알림

아크를 x + 1로 넘겨주는 건 관행.

이 다음엔 호스트 a(클라이언트)가 요청할 것

 

그림에는 빠졌는데 3-웨이 핸드셰이킹의 마지막에 호스트의 Sequence Number는 x + 1이 될 것이다.

그리고 이 이후, 통신이 시작될 것인데, 그 통신의 시작 패킷의 Sequence Number는 x + 1이 될 것이다.

 

연결 종료 = 포 웨이 핸드셰이킹

절받 닫기..

1. 클라이언트는 Fbit 1, seq x => 서버는 Abit 1, ACK x+1

2. 서버는 Fbit 1, seq y, 클라이언트는 Abit 1, ACK y+1

 

이렇게 하는 이유: 서버는 아직 버퍼에서 안 올라온 데이터가 있을 수 있음

---

2-웨이 핸드셰이킹을 안쓰는 이유

송신자의 연결 요청이 딜레이되어 재전송..

그런데 이러면 서버 측에서는 과거의 연결 요청에 대해 응답해서 연결을 켜는 경우가 발생,

클라이언트는 해당 응답은 잘못되었으니 무시

-> 연결이 반 만 켜지는 경우 발생 -> 양방향이 연결이 보장되지 않는 경우 발생