手を振って4とTCP 3ウェイハンドシェイク合意

I.背景の説明

OSIネットワークモデルは、IP層を説明することで、私たちが知っているネットワーク層は、2つのホスト間の通信を実現することができます。しかし、これは、実際にホストにプロセスを通信するエンティティであるため、ホストがデータの交換で別のホストへのプロセスとプロセスであり、具体的ではありません。特定のアプリケーションは、宛先ホストへIPプロトコル・データ・パケットを処理することができるが、ホストに配信されなかったが。通信は、アプリケーションプロセス間の通信の終了でなければなりません。

UDPは、コネクションを確立する必要はありませんデータを転送する前に、UDPパケットを受信した後、リモートホストは、任意の確認を与える必要はありません。UDPは信頼性の高い配信を提供していませんが、それは正確にこのためのものであり、そのようなサービスのリアルタイムの要件の一部として、より速くそれを作る、多くのオーバーヘッドを排除しますが、それは多くの場合、UDPを使用しています。アプリケーション層プロトコルは、主に、DNS、TFTP、DHCP、SNMP、NFSなどの対応します

TCP、コネクション指向のサービスは、あなたが最初の接続を確立する必要があり、データ転送は、データを送信する前に、接続を解除する完了です。したがって、TCPは信頼できるトランスポートサービスであるが、正確には、このため、必然的にそのような確認として、オーバーヘッドの数を増加し、制御フロー。アプリケーション層のプロトコルに対応するには、SMTP、TELNET、HTTP、FTPなどが挙げられます。

第二に、従来よく知られているポート番号

アプリケーション	FTP	TFTP	TELNET	SMTP	DNS	HTTP	SSH	MYSQL
よく知られているポート	21,20	69	23	25	53	80	22	3306
トランスポート層	TCP	UDP	TCP	TCP	UDP	TCP	TCP	TCP

三、TCPの概要

基本的なオブジェクトとしてTCP接続は、各TCP接続は、例えば、ソケットを形成するようにスプライスされるIPアドレスのポート番号として定義され、我々は、エンドソケット（ソケット）を呼び出す両端点を有していますIPアドレスは192.3.4.16、ポート番号が80である場合は、192.3.4.16:80用のソケットを取得します。

四、TCPパケットのヘッダー

1. 送信元ポートと宛先ポート、それぞれ2バイト、書き込み元と宛先ポート、各。
2. 数、4バイト、各バイトのTCPバイトストリームトランスポート接続を順次番号付けされます。例えば、パケット期間のシーケンス番号フィールドの値が301であり、100のフィールドの合計によって運ばれるデータは、（いずれかがある場合）、データ数401から開始する必要があり、明らかに次のセグメントです。
3. 確認応答番号、4つのバイトは、それが望ましい最初のデータバイトは、次のパケットのシーケンス番号の対応を受信します。例えば、Bは、シーケンス番号フィールド501であるAから送信されたパケットを、受信し、及びデータ長が200バイト、送信数700までのデータの正しい受信を示し、Bです。したがって、Bは、Aが、確認応答番号のセグメントが701に設定されているに送信された確認応答でBその後、701で次のデータ数を受信することを期待します。
4. データを、4ビットのオフセット、それがどれだけ近いTCPセグメントの開始時にTCPパケットデータに留意されたいです。
5. ご予約は、将来の使用のために予約、6を占めますが、ビット0を持っている必要があります。
6. 緊急URG、URG = 1は、緊急ポインタフィールドが有効であることを示しています。このセグメントの緊急データが存在するシステムに指示します。
7. ACK = 1、確認応答番号フィールドが有効であるだけ謝辞ACK、。TCP接続が1に設定されなければならないACK送信のすべてのパケットに確立されている提供します。
8. PSHプッシュは、ときに、2つの双方向コミュニケーションアプリケーションプロセス、アプリケーション・プロセスが直ちにコマンドを入力した後、他の応答の終わりを受信できるようにしたいかもしれない、この時点であろうPSH = 1。
9. RST = 1は、重大なエラーは、接続は、接続を再確立解放されなければならない接続TCPで発生したことを示してRSTをリセットします。
10. シリアル接続を同期させるために使用される同期SYNが、確立されます。SYN = 1、ACK = 0は、パケットが接続要求、合意された場合、接続であることを示す場合、応答メッセージが作るべきSYN = 1、ACK = 1。
11. 終了FIN、接続を解除します。FIN = 1、このメッセージの送信者を示すデータが送信された場合、および要件を放出します。
12. ウィンドウ、2バイト、あなたが受け入れるように多くのスペースを必要とする新聞のテキストを送信し、受信者に通知するために参照します。
13. およびテスト、2バイト、及びヘッダチェックサムデータ二つの部分。
14. 緊急ポインタ、緊急データセグメント新聞のバイト数を示す2バイト。
15. オプションは、可変長は、他の任意のパラメータの数を定義しました。

第五に、TCP接続を確立（スリーウェイハンドシェイク）

• クライアントとサーバーの冒頭には、CLOSED状態になっています。クライアントへのアクティブオープン接続、サーバーがパッシブオープン接続です。

1. TCPサーバー・プロセスは、伝送制御ブロックTCBを作成するには、クライアント・プロセスからの接続要求を受け入れるために常に準備ができて、この時点でサーバがLISTEN（モニタ）状態に入ります。
2. TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
3. TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
4. TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
5. 当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

六、TCP四次挥手

• 数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗ *∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

七、面试题

7.1 为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

1. 保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
2. 防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

7.2 为什么建立连接是三次握手，关闭连接确是四次挥手呢？

接続が確立された後、LISTEN状態にあるサーバー、接続要求を確立するために、SYNパケットを受信し、SYN ACKパケットがクライアントに送信されました。接続が閉じているときと、サーバは単に、もはや他の当事者を意味し、お互いのFINメッセージは、自分自身のは、すぐにオフにすることができるので、彼は、お互いに送信されたすべてのデータを持っていないかもしれないが、あなたも送ることができ、データを送るだけでなく、データを受け取る受信しますお互いにいくつかのデータの後、およびその後複数回に得られ、したがって、独自FIN及びACKは、一般的に別々に送信され、今接続を閉じるために同意する反対側にFINパケットを送信します。

すでに接続が確立されているが、クライアントが突然決裂した場合はどのように7.3のですか？

TCPは、障害が発生した場合、サーバは、無駄なリソースを待っているに保つことができない、明らかに、またクライアントキープアライブタイマーです。サーバはクライアントの要求は、タイマーの設定時間をリセットします受信するたびに、通常は2時間で2時間クライアントからのデータを受信して​​いない場合、サーバは検出メッセージセグメントを送信し、その後、すべての75一度秒を送信します。10個の連続したプローブパケットを送信することは、まだ回答は得られなかった場合は、顧客を持ち出し、サーバーが障害と考えられ、その後、彼らは、接続を閉じます。