[네트워크]Transport Layer - TCP

정태규·2023년 4월 27일
0

네트워크

목록 보기
15/19

TCP

✍️connection-oriented

  • 데이타 교환전에 three-way handshake를 한다.

✍️보내진 데이터와 패킷을 순서대로 전달하는 것을 보장한다.

✍️multicasting이 불가능하고 single sender와 single receiver만 연결되어 있다.

✍️full duplex service

  • bidirectional하다. 즉, 양방향 통신이 가능하다는 것이다. 예를들어, 웹서버와 웹브라우저간의 통신에서 서로 데이터를 주고받을 수 있다.

✍️pipelined

  • 응답이 도착하기전에 요청을 보낸다.
  • GBN+SR

✍️flow controlled

  • sender는 receiver가 너무 밀리지 않게 조절한다.

MSS(Maximum Segment Size)

  • segment에서 application layer data의 최대량

    headers를 포함하지 않는다.
    ex) a segment = TCP/IP header + TCP MSS

  • MTU = MSS + TCP/IP header length

TCP segment Structure

sequence number / Acknowledgement number

TCP는 network 통신을 하기위해 먼저 3-way handshake 통신규약을 맺는다.

그러고 나서 Data를 보내는데
1. 먼저 sender가 syn패킷을 보낸다.
2. receiver는 데이터를 잘받았다면 잘받았다고 확인 메세지로 Ack를 보낸다.

receiver가 가지고 있는 window size > sender의 MSS(Maximum segment size) 를 확인하고 이 조건이 맞다면 데이터를 보낸다. false라면 wait가 걸린다.
더 자세히 들어가보자면,
sender 측에서 data를 보내면 receive측의 TCP buffer에서 이걸 받고 있다.
TCP buffer가 data들을 최대로 받고있을 수 있는 크기를 window size라고 하는데,
OS가 관리하는 file I/O buffer가 읽는 속도가 빠르다면 window size가 차기 전에 빨리빨리 읽어들일 수 있지만, 느리다면 window가 꽉차고 sender는 보낼 수 없게 돼서 wait가 걸리고 느려지게 되는것이다. 일반적으로 다운로드 속도가 느린것은, 서버가 느리게 보내는게 아니라 클라이언트가 read속도가 느려서 그렇다.

  1. ack가 올때까지 wait한다. (TCP가 느려지는 이유)
  2. ack가 도착하면 ack에 들어있는 번호를 보내준다.

piggybacking

receiver가 데이터를 받았을때, ack를 즉시 보내지 않고 보낼 데이터가 생겼을때 같이 보내는 것.

  • 장점:네트워크 대역폭을 효율적으로 사용할 수 있다.
  • 단점:ack를 보낼대까지 시간이 오래걸리면 sender는 메세지를 다시 보낼 것이다.

RTT

  • Round Trip time
  • segment가 보내지고 나서부터 segment에 대한 ack를 받을때까지의 시간
  • 네트워크 상태에 따라 달라진다.
  • TCP는 timeout/retransmit mechanism을 사용한다.
    ✍️ timeout이 될때까지 ack를 sender가 못받으면 다시 전송한다.
  • 그래서 RTT < timeout 이 되어야한다.
  • timeout이 너무짧으면 premature timeout -> 불필요한 retransmission이 일어난다.
  • timeout이 너무길면 반응이 너무느려져서 불필요한 waiting time이 길어질 수 있다.

RTT Estimate

✍️ sampleRTT

  • 각 segment가 한번 수행하는 RTT,모두 측정하지 않고 한번에 하나만 측정
  • retransmission은 측정하지 않는다.
  • 값이 매 segment 마다 다르다.

✍️ EstimatedRTT

  • 평균 RTT
  • sampleRTT는 굉장히 가변적이기 때문에 EstimateRTT를 따른다.
  • sample RTT 값이 하나씩 나올때마다 EstimatedRTT는 수정된다.

    평균값을 구하는 방법이다.



sampleRTT는 값의 편차가 크고, EstimatedRTT는 값이 일정한 편이다.

✍️DevRTT

  • safety margin : RTT의 가변성을 측정한 것이다.
  • EstimatedRTT에서 가변성이 클수록 safety margin도 커진다.

3 duplicate Acks

  • Fast Retransmit

지금까지는 timeout을 통해서 retransmission을 했다. 하지만, timeout까지 기다리고 나서 congestion에 반응하는것은 너무 늦다. 그래서 생각한것이 acks가 중복해서 3번 들어오면 해당 ack를 loss로 생각하고 다시 재전송한다.

그렇다면 왜 3번일까?

duplicate가 일어나는건 예를들어, 12345 순서로 도착해야 하는 ack가 1245이런식으로 건너뛰고 도착했을때 3에대한 ack를 계속 보내게 되는것이다. 근데, 이게 congestion이 실제로 일어난건지 단순히 순서만 바뀐것인지 알 수가 없다. 그래서 3번까지는 기다려주는 것이다.

Flow Control

  • receiver의 buffer가 넘처나게 보내지 않도록 조절한다.
    receiver가 읽는속도에 보내는 속도를 맞춰서 보낸다. 보내는게 너무 빨라지면 receiver buffer에서 overflow가 생기기 때문이다.


1.클라이언트에서 서버에 보낼 데이터를 write 한다.
2.데이터가 클라이언트의 송신 버퍼(Send Buffer)에 적재된다.
3.적재된 데이터가 서버의 수신 버퍼(Receive Buffer)에 전송된다.
4.서버가 수신버퍼에 적재된 데이터를 read한다.
5.서버에서 클라이언트에게 응답할 데이터를 write 한다.
6.데이터가 서버의 송신버퍼에 적재된다.
7.적재된 데이터가 클라이언트의 수신 버퍼에 전송된다.
8.클라이언트가 수신버퍼에 적재된 데이터를 read한다.

이 조절은 어떻게 이루어질까?
바로 windowsize로 조절된다.

TCP에는 window사이즈도 같이 저장되어있다.

RcvBuffer(Receive buffer)

✍️RcvBuffer size는 socket option을통해 설정된다.(보통 4096bytes)
✍️OS가 자동으로 RcvBuffer를 조정해준다.
✍️free buffer space인 rwnd에 receive된 data들이 쌓인다.

flow control at sender

ack를 받은 최소의 sequence 넘버까지 window가 지나간다.
예를들어, send 1,2,3,4,5,6 ack 1,2,4,5,6 이면 window가 12를 지나 3~로 설정되어있는 것이다.


receiver는 sender에게 rwnd가 얼마나 남았는지 알려주고, sender는 그에 맞게 window size를 변화시킨다.


sender가 ack를 받기전에 seq를 200을 두번 보냈다. receiver는 buffer에 저장하고 있다가 한번에 ack와 남은 rwnd를 보내준다. 그러면 receiver는 한번에 window 사이즈를 조절한다.


receiver의 buffer가 가득차면 application layer로 보낸다.

Establishing TCP connection

Closing TCP Connection

0개의 댓글