TCP(1)
TCP/IP Illustrated Vol.1 2nd EditionのTCPの章を読み始めたので、備忘録として簡単なまとめを書いておく。
TCP: Transmission Control Protocol
packet 転送中に、packet dropやbit errorに対してどうするのが一番素直？
- ちゃんと届くまで、再送してやれば良い
再送する方法での要求:
- 受信者がpacketを受け取ったという確認できる方法
- 受け取ったpacketが送信者側が送ったpacketと同一であると確認できる方法
→ 受信者は、送信者にpacketを受け取りましたよーという確認用のpacketを送信する(Acknowledgement/ACK)
一連の流れ:
Sender: packetを送信、ACKを待つ
Receiver: packetを受信、ACKを送信
Sender: ACKを受信、他のpacketを送信
(以下、繰り返し)
ここで、疑問がでてくる。
- SenderはどのぐらいACKを待ち続けるのか？
- ACKが消失したらどうなる？
- packetを受信しても、それにerrorが含まれていたらどうなる？
<解答>
- 別の章で解説
- 送信側は、ACKが消失したのか、送ったpacketが届いてないのかを判断することはできないために、もう一度同じpacketを送る。(ただし、受信側は同じpacketを重複して受信する可能性あり)
- checksum と CRC使えばよい
packetを重複(duplicate)して受信したときはどうすればいい？
- sequence numberを用いてpacketを識別
- sequence numberは、unique
TCP: これまでの仕組みをみていると、信頼性はあるけど、効率的ではないよね。
- 例えば、small packetを大量に送るとかすると、delayやlatencyが大きい回線(e.g. 衛星回線)を利用した場合とか
- 送信側は、ひとつのpacketを送ると、ACKを受信するまでは待たなければならない
- スループット性能(単位時間あたりにおけるデータ転送量): M/Rに比例 (M: packet size, R: RTT(応答遅延時間), ただし、packet loss等はなし)
- スループット性能は、固定長packetで、R(RTT)が大きくなるとスループットは下がる
"Window" of packets
