[네트워크] 연결 지향 전송(TCP)

네트워크 관련 글 순서(참조 영상 기준)

애플리케이션 계층
- 네트워크 애플리케이션의 원리
- DNS
- TCP를 이용한 Socket 프로그래밍

전송계층
- 전송 계층 서비스의 원리
- rdt 원리
- 연결 지향 전송: TCP
- TCP 흐름 제어(3-way handshake, 4-way handshake)
- TCP 혼잡 제어

네트워크 계층
- 네트워크 계층 서비스
- Network Address Translation(NAT), DHCP
- 라우팅 알고리즘(Link State, Distance Vector)
- 계층적 경로 변경(AS)

링크 계층
- 다중 엑세스 프로토콜
- LANs(근거리 통신망)

무선 및 모바일 네트워크
- 무선 네트워크

웹 요청 시 일어나는일

네트워크 보안
- 대칭키 & 공개키,RSA 암호화
- Secure e-mail, SSL, MAC
- IPSec(ESP), Firewall(방화벽)

 

TCP이란

데이터를 보내기 위해 사용되는 전송계층의 프로토콜.

 

TCP 특성

• point - to - point: tcp는 한쌍의 소켓으로 이루어져있다. 한쌍의 소켓을 위해서만 동작한다.
• reliable, in-order byte stream: 신뢰성^[각주:1]있고, 데이터에 순서가 있다.
• pipelined: 파이프라인 방식. 전송 후 대기 형태가 아닌 데이터를 한꺼번에 많이 보내고, 보낸것들에 대한 응답 또한 한꺼번에 받을 수 있는 방식.
• full duplex data: 각각의 소켓이 send이자 recive 두가지 다 한다. 데이터를 보내고 받고 다 한다.
• connection-oriented: 연결지향

 

TCP 헤더 구조

헤더 구조

 

헤더와 데이터로 나누어져있음

 

• Source, Destination Port: 시작 끝 포트 번호
• Sequence Number: 데이터 순서 정보.
• Acknowledgment Number: 피드백 데이터 순서 정보(수신측). 밑에서 설명 예정.
• Offset, Reserved, Flags: 헤더 제외 데이터 시작 위치. 미래를 위해 예약된 필드. 세그먼트 속성 비트 플래그.
• Window Size: 한번에 전송할 수 있는 데이터 양.
• Checksum: 오류 검출을 위한 값
• Urgent Pointer: 긴급 포인터.
• Option: 기타 옵션.

 

옵션을 제외한 기본 헤더가 20Byte. 옵션이 최대 40Byte. 총 최대 60Byte까지 가능.

데이터는 별도.

 

 

TCP 동작 원리

한개의 TCP가 구성이 될때, 각 소켓에 두개의 버퍼 생성

SEND Buffer, RCV Buffer

 

이러한 버퍼가 쓰이는 이유는 애플리케이션에서 소켓을 통해 데이터가 내려오는 속도와, 전송계층에서 TCP를 통해 데이터가 나가는 속도가 다르기 때문에 버퍼어 데이터를 쌓아두었다가 나간다.

 

SEND Buffer: 전송되어야할 데이터가 쌓이는 버퍼.

RCV Buffer: 다른 소켓에서 전송받아온 데이터가 쌓이는 버퍼( 추후 애플리케이션에 올릴 데이터)

 

TCP엔 Window Size가 존재하는데, 이 WS만큼씩 데이터를 보낼 수 있다.(Sliding Window 방식)

예를 들어, 윈도우 사이즈가 1000이고, Send Buffer에 그만큼의 데이터가 쌓여있다면, 0~999까지의 데이터가 전송된다. 이때 데이터는 세그먼트 단위로 전송되어지는데, 최대 세그먼트 크기가 200byte라고 가정하면,

0~199, 200~399, 400~599, 600~799, 800~999 로 나눠서 전송된다.

 

이때 데이터의 순서를 보장하기위해 세그먼트 헤더에 sequence number가 쓰인다.

전에 RDT에서 얘기했던 0,1 형태^[각주:2]가 아니라 바이트로 붙게되고,

데이터의 시작 바이트가 시퀀스 번호가 됨.

(0~199면 시퀀스 번호는 0, 200~399면 시퀀스번호 200)

 

전송된 세그먼트는 다른 한쌍의 소켓안의 RCV Buffer가 받고, 잘 받았다는 의미로 피드백(세그먼트)을 전송한다.

이때 어느 데이터까지 잘 받았는지 알리기위해 세그먼트 헤더에 Acknowledgment Number(이하 ack)를 넣고 보낸다.

(ack200이란 것은 199번까지 잘 받았고, 200번을 기다리는 중이라는 의미)

 

피드백을 받게되면, 그때 window도 이동한다. window안에 있는 데이터를 전송 가능해진다.

 

보내진 데이터가 유실되었을 경우엔, 설정된 Timer 초과하면 재전송한다.

 

타이머 설정 방법

타이머 값에 대한 세팅은 갔다가 돌아오는 시간(RTT)를 측정해서 이것보다 좀 더 많게 설정한다.

RTT는 매번 세그먼트를 보낼때마다, 나가는 순간부터 피드백이 돌아올때까지를 체크한다.(Sample RTT)

 

주의사항:  시퀀스 500에 데이터(200 byte)을 보내면, 피드백이 ack 700이 와야하는데 유실되면 재전송을 보냄.

추후 피드백이 오면 이전에 보낸것에 대한 답인지, 재전송한것에대한 답인지 모른다.

그렇기때문에 재전송을 보낸 RTT는 포함시키지 않음.

 

RTT는 매번 다르게 나오는데, 이유는 각 세그먼트가 보내질때 네트워크의 상황이 다르기때문에 RTT가 달라진다.

 

 

그렇기때문에 변화무쌍한 RTT를 적용시키진 못하므로, 트렌드를 구해서 적용시킨다.

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

 

a 값[알파를 뜻함]은 0.125로 지정(엔지니어가 정한것...)

 

이렇게 구한 rtt에 여유 마진을 두어서 timer를 설정

 

TCP 시나리오

 

타이머는 한 소켓에 한개가 존재

타이머는 첫번째 세그먼트에 맞춰서 진행된다.

그래서 피드백을 받으면, window도 받은만큼 이동해지고 타이머도 다음에 보낼 세그먼트에 물려서 진행된다.

 

0번 시퀀스에 해당하는 세그먼트를 받았고, 애플리케이션에 데이터를 보낸 후

뒤에 200 세그먼트는 오지않고 뒤의 순서 400,600,800 세그먼트가 도착했을 경우,

피드백은 200 ACK를 다음에 받아야한다고 보낸다.

 

reciver측에선 지금 받은 400,600,800 등을 위로 올리지않고, 200을 기다립니다.

 

추후, 재전송한 200이 도착했을때 한번에 올리게 되고, 피드백은 다음에 받아야할 1000ACK를 보내게 된다.

피드백을 받으면 Window도 해당하는만큼 그제서야 이동하게 된다.

 

send buffer에선 보냈다고 데이터를 바로 안지우고 window를 뒤늦게 이동시키는 이유는 혹시라도 재전송할 경우도 있을까봐다.

 

피드백 보낸게 유실되었을 경우 timer가 초과되고 다시 재전송한다.

 

 

한가지 아쉬운점은 데이터가 유실되었을때, timer가 초과해야 재전송하는데 timer가 초과하는시간은 굉장히 여유롭다.

그래서 보다 빨리 유실되었다는것을 파악할 수 있다면 좋은데, 

이때 유실된 데이터 뒤의 데이터가 받아져서 피드백을 보낸다면, 유실된걸 파악 가능하고 관련 데이터를 재전송한다.

내부 구조로는 동일한 피드백을 3번 받았을때, 유실된것으로 파악하고 재전송한다.

(뒤에 흐름제어에서 설명함)

 

 

버퍼에서 애플리케이션으로 데이터가 올라가거나, 버퍼로 데이터가 내려오는 것은 개발자가 정하는것.
socket.read() 일때 애플리케이션으로 데이터가 올라가고, write할때 버퍼로 데이터가 내려감.

 

 

---

참조

 

KOCW 네트워크 강의 - 한양대 2018 1학기 이석복 교수님

컴퓨터네트워크

 

1. 데이터유실없이 에러없이 [본문으로]
2. stop and wait 방식에서 쓰임. 흐름제어의 한 방법. 현재 설명하는 것은 sliding window 방식 [본문으로]