network - transport layer(3)

* TCP

point to point

- 엔드 시스템에서만 작동

- 엣지에서만 작동

- 순서가 바뀌지 않고 장애가 없음

 
신뢰적인 in-order byte stream
- 순서가 바뀌지 않고 장애가 없음

- Message에 구분이 없다.

 

pipelined
- 혼잡제어나 흐름제어를 통해 window size를 제어.

- 단, 흐름제어는 크게 신경쓰지 않는 경우가 많다.

 

buffer
- 송,수신측은 buffer를 가짐.

 

full duplex
- 동일 connection에 양단이 동시에 data를 전송 할 수 있다.

- MSS : maximum segment size(segment에서 app layer data의 최대 크기)

 

connection oriented
- handshake를 먼저 수행.

 

Flow control(흐름 제어)

- receiver에서 수행

- sender가 receiver를 압박하지 못하도록 receiver가 전송량을 통제.

 

* TCP segment의 구조

source port #

- 송신자의 port number

 

dest port #

- 수신자의 port #

 

sequence number

- packet의 byte stream number

 

acknowledgement number

- 상대방이 다음에 받아야 할 packet의 sequence number

- 누적 ACK(만약 5000이라면 4999까지 잘 받았다는 의미)

 

header len(gth)(4bit)

- options가 만약 생기면 늘어날 수 있음

 

not used(6bit)

- header length의 다음 6bit는 아직 사용하지 않음.

 

U(URG)

- urgent point 

- 1이면 urg data pointer를 읽어야하고, 0이면 무시.

- 현재는 사용하지 않아서 U와 urg data pointer 모두 사용하지 않아 쓰레기값이 들어있음

 

A(ACK)

- 1이면 acknowledgement number를 읽고, 0이면 무시

- 0이면 응답 패킷이 아니라는 의미

 

P(PSH)

- packet의 우선순위를 정함

- 사용하지 않음. 

 

R(RST)

- 1이면 tcp connection을 reset(초기화)

- reset의 의미는 연결을 끊지않고 기존의 socket을 유지하면서 접속을 초기화.

- client나 server 누구나 먼저 보낼 수 있음

 

S(SYN)

- client가 먼저 보냄

- syn signal. 접속이 없어서 접속을 하기위해 신호 

- 첫번째 신호는 client가 server에게 1을 보내고 server가 client에게 다시 1을 보내고 세번째 신호를 

- sequence number와 window size에 대해서 주고 받음.

- 3번째 신호는 의미가 없음.

- syn flooding 공격에 사용됨.

 

F(FIN)

- 대부분 client가 먼저 보냄.

- 접속을 끊는 것.

 

receive window 또는 flow control용 window size

- 패킷을 보낼때마다 가용할 수 있는 메모리 버퍼 사이즈를 알려줌.

- 일종의 흐름제어

 

checksum

- 패킷이 손상됐는지 확인

- IP와 달리 전체 packet이 깨졌는지 확인

 

urgent point(urgent data pointer)

- 사용하지 않음

 

옵션 및 데이터

- 대부분 존재하지 않음. 

 

christmas packet

- R과 S, S와 F는 동시에 1인 경우가 존재할 수 없는데 R, S, F중 2개 이상이 1인 패킷

- destination port의 application(서비스)이 구동(반응)중인지 확인해보기 위해서 보냄.(=스캔) 

- 스캔 공격에 사용되기도 함.

 

* TCP sequence number와 ACK

sequence number 

- segment의 첫번째 byte의 stream에서의 byte 순서 번호

- 시작 sequence number는 종료된 접속의 남아있는 segment와 유효한 segment와의 혼동을 막기위해 임의로 선택

 

ACKs 
- 다음에 받을 첫번째 byte의 순서 번호
- Cumulative ACK가 가능.
- 만약 순서가 틀린 segment를 수신한 경우에는 즉시 버리거나 buffering(중간에 빠진 data를 받기 위해)한다.)

seq=42, ACK=79, data='C'

- a(client)가 b에게 c라는 data를 보냄.

- 내가 지금 보내는게 sequence number는 42번, ack는 78번째 byte까지 잘 받았고 79번째 byte부터 보내라는 의미

 

seq=79, ACK=43, data='C'

- b가 다시 a에게 c라는 data를 보냄.

- 내가 지금 보내는게 sequence number가 79번, ack를 42번까지 잘 받았고 43번째 byte부터 보내라는 의미

 

* RTT & Timeout

- time out이 rtt보다 짧으면 재전송이 너무 많이 이뤄지고 길면 segment 손실에 대한 대응이 늦어짐

- 따라서 time은 rtt보다 조금 더 길어야 한다.

estimatedRTT

- SampleRTT의 가중 평균 값

- 측정값의 12.5%만 적용. 권고사항이기때문에 반드시 지키는 것은 아님. 

 

SampleRTT

- 실제로 측정된 RTT

- segment가 송신된 시간으로 부터 ACK가 도착한 시간간격

- 재전송 segment는 무시

 

devRTT

- sampleRTT가 estimatedRTT로 부터 얼마나 벗어나느지에 대한 예측

- sampleRTT가 얼마나 변동이 심한지를 의미한다고 볼 수 있음.

- netwokr가 불안하면 devRTT가 커지고 안정되어있다면 devRTT가 작아진다. 

 

timeout 설정

- time out이 rtt보다 짧으면 재전송이 너무 많이 이뤄지고 길면 segment 손실에 대한 대응이 늦어짐

- 따라서 time은 rtt보다 조금 더 길어야 한다.

- EstimatedRTT보다 약간의 여유값을 더한 값으로 설정

- 실제 timeout의 설정은 EstimatedRTT + 4*DevRTT로 한다.(반드시는 아님)

 

* TCP RDT(reliable data transfer)

- TCP는 비신뢰적인 IP 상위에서 신뢰적인 통신 서비스를 제공.
- Pipelined segment 사용
- 누적 ACK 사용.
- TCP는 segment 각각에대한 timer가 아닌 단일 재전송 timer를 사용.
- 전송 segment 각각에 대한 timer는 개념적으로는 쉽지만 overhead가 크다.
- timeout, 중복 ACK이 일어나면 재전송 한다.

- 간소화된 TCP sender는 중복 ACK, 혼잡제어, 흐름제어 무시

 

* TCP sender event

1. application으로 부터 data 수신 
- sequence number를 가진 segement 생성
- sequence number는 첫 번째 byte의 byte stream 번호 
- timer 시작(다른 segment에서 의해서 timer가 작동중이 아닌 경우)
- timer의 만료 주기는 timeoutInterval

 

2. timeout

- timeout을 일으킨 segment를 재전송
- timer 재시작

 

3. ACK가 확인되지 않은 segment의 ACK인 경우
- ACK의 sequence number가 sendbase보다 크면 이전에 확인되지 않은 segment에 대해 확인하고 sendbase를 갱신 
- 아직 확인 응답 안된 segment가 존재하면 timer를 재시작.

 

* TCP 전송 경우의 수

1. ack가 loss 됐을때 

 

- a가 시퀀스 92번부터 8bye인 data를 99번까지 보냄

- ack가 100인 packet을 보냈는데 loss

- a가 다시 보내고 이번에는 응답

- 이 그림은 pipeline을 하지 않음

 

2. time out 

- sequence number가 92, data가 8byte인 packet 전송.

- sequence number 100으로 이동

- sequence number가 100, data가 20byte인 packet 전송.

- ack 100이 오기전에 timeout이 발생해서 sequence number가 92, data가 8byte인 packet 재전송.

- ACK가 100인 packet을 기다리는데 100인 packet과 120인 packet이 둘 다 날라와서 sendbase를 100으로 옮겼다가 다시 120으로 이동

- 그 다음에 한번 더 오는 ACK가 120인 packet은 그냥 무시

 

3. 누적 ACK인 경우 

- sequence number가 92, data가 8byte인 packet 전송.

- ACK가 100인 packet을 보내다가 loss

- sequence number 100으로 이동

- sequence number가 100, data가 20byte인 packet 전송.

- ACK가 120인 packet 전송

- 기다리던 ACK가 100인 packet은 안오고 ACK가  120인 packet이 들어옴

- sendbase는 ack가 120인 packet을 보고 100인 packet이 들어오지 않았지만 send base를 120으로 옮김

 

TCP의 생성 권고

* TCP의 빠른 재전송

timeout이 유발하는 재전송의 문제
- timeout이 길어 segment를 잃어 버렸을때 송신자를 기다리게 해서 종단간 지연이 증가.

 

중복된 ACK와 segment loss
- 수신자는 기다리는것보다 큰 sequence number의 segment를 수신하면 이를 buffering하고 중복 ACK를 전송
- segment를 손실하면 많은 중복된 ACK가 전송 됨.

 

3번의 중복된 ACK가 sender에게 전송된 경우

- 해당 segment가 loss되었다고 판단 
- 이 경우에는 timeout이전이라도 해당 segment를 재전송(fast retransmit)

ex) sequence number가 10, 20, 30, 40, ...일때 20이 loss되면 그 이후의 packet을 보낼때 마다 ACK(20)이 중복해서 sender에게 전달.