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은 따로 정리하도록 하겠습니다 ~