Computer Network(Top-down) - Transport Layer
It is just my opinion, so don't you attack me. please!
But if this posting has some incorrect informations, you comment about that
Please!!
Transport Layer
Network to Transport
· 네트워크 단에서 packet들이 모여서 transport에서 segment가 되고 랜카드의 IP와 헤더의 IP를 비교하고 맞다면 transport까지 올라가고, transport layer에서 Port Number를 확인하고 어떤 응용프로그램으로 갈지 결정
· UDP의 경우, 처음에 보낼 때, 목적지IP와 port, 그리고 자신의 IP, port를 보낸다. 즉 비 연결형이기 때문에 1 : 1로 대응 되는 반면, TCP의 경우 4가지 항목이 전부 있어야하며 session만 유효성이 있다면 같은 IP의 서로 다른 port를 통해 다른 응용프로그램에도 데이터를 전달할 수 있다.Reliable Data Transfer
· rdt 1.0 밑에 채널이 완벽하다고 가정, bit error는 없고, loss도 없다.
· rdt 2.0 ACK, NAK의 출현, NAK의 경우 재 전송을 위한 소스가 추가 된다.
✔︎ 데이터에 대한 에러는 검출할 수 있게 되었지만, ACK, NAK에 대한 에러는 검출 할 수 없다.
· rdt 2.1 Packet에 넘버를 붙이고, 중복된 패킷을 걸러 낸다. ACK과 NAK에 error가 있다면 무조건 재전송을 요구한다.
✔︎ 기본적으로 stop & wait이고, pkt number는 0, 1만 있는 것은 아님(stop & wait 인 경우 0 하고 1만 있으면 됨)
✔︎ 0을 기다리는데 Seq1이 도착한 경우 → receiver에서 1번을 잘받아서 ACK을 보냈는데 ACK이 에러가 있어서, sender가 다시 1번을 보낸다. 이후 receive가 1번에 대한 ACK을 다시 보내준다.
✔︎ Receiver는 sender 쪽에서 마지막 ACK/NAK을 제대로 받았는지 모른다. → ACK/NAK은 시퀀스가 없기 때문이다.
· rdt2.2 NAK 없이 마지막으로 잘 받아진 패킷에 대한 ACK을 보낸 방식이다.
· rdt3.0 loss가 발생했을 때 이전 버전에서는 아무런 액션을 취하지 않음. 여기서는 Timer가 출현한다.
✔︎ delay되어 온 경우 seq number로 handling 가능하다
✔︎ sender가 ack 0번을 기다리는데, ack1 이나 에러이면 아무런 행동도 취하지 않는다.
✔︎ sender는 Timeout이 일어난 경우, 다시 보낸다. 0번에 대한 ack이 제대로 왔다면 timer stop → 1번 데이터가 위에서 내려오길 기다고, 이 상태에서는 ack을 기다리는 상태가 아니기 때문에 패킷을 받을 필요가 없음.
✔︎ receiver쪽에서는 기다리는 패킷이 달라도 ack을 다시 보낼 필요가 없다. 왜냐하면 timer가 있기 때문에 Timeout이
발생하면 sender 쪽에서 자동으로 다시 보낸다.Pipelining
· Go-back-N
✔︎ n개의 패킷을 ack 없이 보낸다. ACK 없이 3개의 패킷을 밀어 넣으면 3배 정도의 효율 향상을 기대할 수 있다.
✔︎ 최대 n개의 패킷을 밀어 넣을 수 있다. Receiver는 cumulative ack을 보낸다. (순서대로 잘 받아진 패킷의 마지막에 대한 ack을 보냄), sender는 ack을 받은 가장 오래된 패킷에 대한 timer를 가지고 있고 timeout이 발생하면 재전송을 한다.
· Selective repeat
✔︎ 각각에 대한 pkt에 대한 ack을 보내고, N개의 패킷을 보낼 수 있고, sender는 각 패킷에 대한 timer를 가지고 있다.TCP Three-handshaking
Alice ---> Bob SYNchronize with my Initial Sequence Number of X
Alice <--- Bob I received your syn, I ACKnowledge that I am ready for [X+1]
Alice <--- Bob SYNchronize with my Initial Sequence Number of Y
Alice ---> Bob I received your syn, I ACKnowledge that I am ready for [Y+1]
It's four-handshaking but we make it short.
ob <--- Alice SYN
Bob ---> Alice SYN ACK
Bob <--- Alice ACK
so then, why not just use a two-way handshaking?
two-way handshaking을 할 경우, 한 쪽만 establish 될 수 있기 때문이다. 다음과 같은 경우에 발생한다.
- Client가 connection_request에 대한 Ack을 받지 못해서 다시 전송 하게 된다.
- 하지만 Server쪽에서는 먼저 보냈던 connection_request에 대한 답을 보냈고, Client가 받았다. 받음과 동시에 session이 열린다.
- session이 열려서 Client는 data_A를 보낸다. Server에서 data_A에 대한 Ack을 보냈지만 loss가 발생한다. 이후 data_A가 timeout이 나게 되고, Client는 data_A를 다시 전송한다.
- 이후 어떠한 이유 때문에 client가 session을 종료 시킵니다. 동시에 Server는 connection에 대한 것을 잊어버린다.
- session이 종료되고, 1에서 재 전송한 connection_request가 도착해서 Server는 establish 상태가 되고, 이어서 3에서 재 전송한 data_A가 Server 도착할 수 있다.
여기서 발생한 문제점은 Server는 Client와 연결된 상태가 아님에도 Client로 부터 데이터를 전송 받아버렸다.라는 것이다.
양이 너무 많아서 flow control, congestion control은 따로 정리하도록 하겠습니다 ~