티스토리 뷰

Study/Network

[Networking] TCP service model (2)

생각많은 소심남 2016. 8. 30. 22:08

  TCP Connection이 생성된 이후에는 Host 사이에는 일종의 stream 형태로 data 전달이 이뤄진다.

Host A가 B를 향해서 Data를 전달하는 과정인데, html 파일을 여는 과정이나, video streaming을 하는 경우에도 위와 같은 data 전달이 이뤄진다.

당연히 여기서 초점을 맞춰야 할 부분은

 - Host A가 B에게 원하는 data를 정확하게 전달하였는지?
 - 전달한 Data가 순서에 따라서 보내진게 맞는건지?

일텐데, 이를 보장하기 위한 방법들이 있다. 아무튼 이런 data stream은 이전 포스트에서 소개한 TCP segment를 통해서 전달된다. 그러면 위와 같은 그림도 이전 포스트에 다뤘던 것과 같이 encapsulation되는 과정을 표현할 수 있게 된다.

 

위의 그림처럼 Host A에서 생성된 data들은 TCP header와 합쳐져서 TCP segment로 생성되고, 이 것은 다시 Host B로 전달되어 decapsulation된다. 

 물론 그림을 통해서도 알겠지만 한번에 TCP segment에 담을 수 있는 data 량이 유한하기 때문에 여러번에 나눠져서 전달될 수도 있고, 어떤 경우에는 중간에 TCP segment가 제대로 전달되지 않을 수 있다. 참고로 TCP segment에 담을 수 있는 데이터량은 정하기 나름이다. ssh같은 형식을 쓰면 한번 데이터를 보낼때 한 byte씩 보낼수도 있고, 다른 형식에서는 보내는 데이터량도 조절할 수 있다. 물론 많은 데이터를 보낼 때는 한번에 하나씩 보내는 방식은 비효율적이 되기 때문에 일반적으로 많은 데이터량을 보내고자 할때는 IP datagram의 최대 크기만큼 보내기도 한다.

 이렇게 data가 정상적으로 전달이 완료된 경우라면 둘 사이의 connection을 종료(teardown)시켜야 할때도 있다.이 때도 이전 포스트에서 다뤘던 3-way handshake와 방식이 비슷하다. 다만 Ack가 오는 과정에서 조금 차이가 있다.

우선 Connection을 끝내고자 하는 Host A는 B에게 Fin 메세지를 보낸다. 그러면 B도 이에 대한 반응으로 Ack를 보낸다. 앞에서 다룬 3-way handshake와 다른 부분이 바로 여기인데, 이 Ack를 보낼때 B가 A한테 보낼 data들을 함께 보내게 된다. 이게 한번에 그치는 것이 아니라 B가 A에게 보낼 data 전체를 나눠서 보내는 것이다.

connection은 B가 A에게 보낼 data를 모두 보내고 난후 최종적으로 Fin 메세지를 보내고 나서야 되고 A도 역시 이 Fin 메세지에 대한 Ack를 B에게 보냄으로써 마무리된다. Fin을 보낼때 남은 data를 보내고 나서야 teardown이 되는 점이 앞에서 말한 3-way handshake와 다른 부분이다.

 TCP service model을 요약하면 다음과 같다. 이중 다른 프로토콜과는 다르게 TCP만의 특징이 될수 있는 부분이 Reliable delivery이고, 총 4가지 메카니즘을 통해서 data가 전달된다.

 1) 정상적으로 data 전달이 이뤄진 경우에는 Receiver가 Sender에게 ACK(Acknowledge) 메세지를 전달한다.
 2) checksum을 통해서 데이터의 손실 여부를 판단한다. checksum은 TCP segment 중 TCP header에 포함되어 있는 내용인데, 현재 segment가 손실되었는지를 판단할 수 있게 해준다. 보통 손실이라고 하면 Wire간의 data 전송시 bit-error가 발생하던가 중간에 전달되면서 거치는 path중 memory fault가 발생해서 나타날 수 있다.
 3) header에는 checksum외에도 sequence number도 가지는데 앞에서 잠깐 소개한 order number라고 보면 좋을거 같다. 즉 전달된 data의 순서를 표현하고, 이를 통해서 중간에 빠진 데이터가 있는지 여부도 확인할 수 있다. 예를 들어 첫번째 segment를 전달했을 때 sequence number가 1000이 되었고, 다음에 전달될 segment의 크기가 500일때 이 segment의 sequence number는 1000+500=1500을 가리켜야 하는 것이다. 물론 segment가 전달되지 않을경우, 이 sequence number는 다를 것이고, 이를 통해서 TCP layer는 받은 데이터가 정확하지 않다는 것을 알게 된다. 이 경우 receiver는 sender에게 다시 보내달라는 신호를 전달하게 된다.
 4) Flow control를 통해서 전달되는 data 양을 조절할 수 있다. 예를 들어 Host A가 B보다 동작 속도가 빠를 경우, A가 데이터를 전달하는 속도가 B가 감당하기 어려울 만큼 빠를 수 있다. 이때 receiver쪽 TCP layer가 flow control을 통해서 둘간의 speed를 조절하게 된다. 뭐 직접적으로 속도를 조절한다기 보다는 receiver가 sender에게 자기에게 남아있는 buffer의 크기를 알려주는 형태인데, 이를 통해서 A가 B를 향해 data를 더 전달할 수도, 혹은 덜 전달할 수 있다.

In-sequence 측면은 바로 앞에서 나온 sequence number와 맥락이 비슷한데, sender에서 보낸 data의 order는 receiver에서도 동일한 order로 받아져야 한다는 것이다. 물론 이 순서가 다를 경우, TCP layer는 상대방에게 sequence number를 이용해서 다시 정상적으로 보내라는 요구를 하게 된다. 

 congestion control에 대한 내용은 추후에 정리하고자 한다.


그림 출처 : Staford University - Networking - Unit 2-1 : TCP service model 강의자료

'Study > Network' 카테고리의 다른 글

[Network] ICMP Service Model  (0) 2018.01.24
[oFono] Overview  (0) 2017.11.17
[Networking] UDP service model  (0) 2016.09.06
[Networking] TCP service model (3)  (0) 2016.08.30
[Networking] TCP service model (1)  (0) 2016.08.30
[Network] Nash Equilibrium 문제  (0) 2015.03.02
[Network] End-to-end Principle  (2) 2014.02.06
댓글