성장하고 싶은 신입 개발자

TCP의 특징

1) Full duplex data transfer

           - 데이터 통신을 할 때 양방향으로 데이터가 흐른다.

2) Connection-oriented

           - 통신을 하기 앞서 Handshaking 과정을 통해 sender와 receiver의 상태를 확인한다.

3) Flow controlled

           - sender는 receiver의 상태를 살펴보며 전송량을 조절한다.

4) Reliable, in-order byte stream

           - 데이터는 순서대로 application layer로 넘겨지며, 데이터를 byte로 처리하기 때문에

             application message의 맥락을 신경쓰지 않는다.

5) Pipelined

           - TCP congestion, flow control이 pipeline을 위한 윈도우 사이즈를 결정한다.

TCP 입출력버퍼

• TCP 소켓의 데이터 송수신에는 경계가 없다.
  아래와 같은 데이터의 처리를 하기 위해 tcp 통신에서는 입력 버퍼와 출력 버퍼가 필요하다.
  1. 송신측에서 write()로 여러 데이터를 몇 번에 걸쳐 보내도 수신 측에서는 read() 한 번으로 그 데이터들을
     한번에 수신한다.
  2. 송신측에서 용량이 큰 데이터를 write()로 보내도 수신 측에서는 read()로 데이터를 여러번 나누어 수신할 수 있다.
  
  
  

TCP 입출력 버퍼의 특징

• 입출력버퍼는 tcp 소켓 각각에 별도로 존재한다.
• 입출력버퍼는 소켓 생성시 자동으로 생성된다.
• 소켓을 닫아도 출력버퍼에 남아 있는 데이터는 계속 전송된다.
• 소켓을 닫으면 입력버퍼에 남아 있는 데이터는 소멸된다.
  -> 소켓을 닫았을 때 read()로 입력버퍼에 있는 값을 가져오려고 하면 read()는 -1을 반환한다.
• 수신자가 데이터를 수신하는 시점 == 송신자가 write()를 호출했을 때가 아닌, 수신자가 read()를 호출했을 때!!

TCP의 pipelining

           - TCP는 패킷을 보낼 때 pipeline을 통해 전송한다.

            -> pipeline방식으로는 Go-Back-N과 Selective repeat 방식이 있는데,

                TCP는 두가지 방법을 혼합하여 사용한다.

            ( GBN방식처럼 중간에 패킷 하나가 빠지면 빠진 패킷에 대한 ack을 계속 전송하며,

              retransmission timer는 하나만 설정한다. 또한 selective repeat 방식처럼

              순서에 맞지 않게 온 패킷들도 버퍼에 다 보관해 놓는다. )

TCP의 sequence number

           - TCP에서 sequence number는 application data의 양만큼 증가한다.

             ex) 하나의 패킷의 크기가 8bytes라면, sequence number는 1,9,17,25 …

                 이런 식으로 증가한다.

TCP의 ack number

           - TCP에서 ACK번호 == “내가 너로부터 받기로 예상하는 sequence number”

           - ACK번호를 받으면 바로 다음 턴에 ack에 해당하는 패킷을 보내줘야 한다.

TCP Header

           - UDP에 비해 굉장히 복잡한 형태를 가지고 있음.

             acknowledgement number와 window size

                 => receiver가 필요한 정보를 실어 보내는 것

             나머지 부분

                 => sender가 필요한 정보를 실어 보내는 것

TCP round trip time ( RTT )

           - RTT : 특정 패킷을 전송하고 다시 응답을 받기까지 걸린 시간

           - TCP에서는 기본적으로 retransmission timer를 사용하므로, 예상 RTT를 계산하는 것

             이 매우 중요함!!

             retransmission timer < RTT 인 경우

                => 패킷이 유실되지도 않았는데 재전송하는 경우 발생

             retransmission timer > RTT 인 경우

                => 패킷이 유실되는 경우에 늦게 반응하는 속도 저하 발생

TCP fast retransmit

           TCP에서 패킷이 유실된 것을 의심해볼 수 있는 경우 2가지

           1. 중복된 ack이 계속해서 오는 경우        

           2. timeout이 발생한 경우

           -> 유실이 된 것으로 의심이 되면 빠르게 재전송을 해야 하는데 타이머의 timeout을 기

              다리는 것은 굉장히 답답하다. 한번에 여러 패킷을 보냈다고 하더라도 가장 첫 패킷

              에 대한 ack이 오고 나서야 다음 패킷에 대한 타이머가 시작되어 굉장히 느리다.

           위 문제점 해결 방법

                      - TCP fast retrasmit 방식 사용

                                 -> 재전송을 timeout에 의지하지 않고 중복된 ack메시지가 올 경우

                                      패킷이 유실된 것으로 추정하고 바로 재전송하는 방식

TCP Flow control

           - receiver의 buffer 눈치를 보고 sender의 window size를 조절하는 것

           - TCP에서 flow control은 receiver측의 소켓에 존재하는 버퍼를 기준으로 삼는다.

       동작방식

           - 소켓의 버퍼에 데이터가 계속 쌓이면, application layer에서 데이터를 계속 가져간다.

             이 때 application layer에서 데이터를 가져가는 속도보다 버퍼에 데이터가 쌓이는 속도

             가 큰 경우 데이터가 유실될 수 있다

             => 이럴 경우 receiver측의 소켓 버퍼 상황을 고려하여 window size를 조절하는 것이

                 바로 TCP flow control이다.

             => flow control은 sender가 조절하는게 아닌 receiver가 sender에게 명령하는 것

                 ( 나 상황 이러니까 너가 보내는 속도 조절해라 sender야~~^^ )

       TCP persist Timer

            - sender가 receiver버퍼에 빈 공간이 있는지 알아보려고 주기적으로

              1byte짜리 메시지로 찔러보기 위한 타이머

결론

     1. pipelined된 패킷 통신을 할 때는 window가 존재하는데, TCP header에 수용 가능한

        window크기가 적혀있다.

     2. TCP flow control은 receiver의 소켓 버퍼가 수용 가능한지를 따져 sender가 전송량을

        조절하는 것이다.

    3. receiver의 소켓 버퍼가 가득 차있다가 여유가 생기면 sender에게 알려준다.

       동시에 sender는 receiver에게 여유가 있는지 주기적으로 계속 찔러보는데

       이를 TCP persist Timer라고 한다.