1、とのTCP 3ウェイハンドシェイク（スリーウェイハンドシェイク）
それらの間の接続を開始すると同時に、端子の一対が可能です。しかし、通常のソケット（ソケット）の終わりで開かれ、一般的にパッシブオープン（受動的オープン）と呼ばれ、相手からの接続を待ち受けます。サーバがオープンパッシブた後、エンドユーザーがアクティブオープン（アクティブオープン）の作成を開始することができるであろう。
（1）最初のハンドシェーク：
クライアントSYNフラグビットが1にセットされ、ランダムに生成された値の配列= Jを、パケットがサーバーに送信され、クライアントが肯定応答サーバを待って、SYN_SENT状態に入ります。
（2）第2のハンドシェイクは：
接続を確立するためにサーバフラグSYN = 1クライアント要求を知っているからデータパケットを受信した後、サーバSYNとACKフラグビットが1に設定され、ACK = J + 1、ランダムに生成された値の配列= K、およびクライアントに接続要求を確認するためにデータパケットを送信し、サーバーがSYN_RCVD状態に入ります。
（3）第三のハンドシェイクを：
クライアントが肯定応答は、ACK J + 1か否かをチェック、ACKが1であり、正しいACKフラグが1に設定されている場合、ACK = K + 1、及びデータパケットを受信します正しい場合は、接続が確立されるサーバー、サーバーをチェックしたack K + 1かどうかに、ACKが1で、クライアントとサーバーは、確立された状態になり、3ウェイハンドシェイクを完了し、その後、クライアントとサーバー間のデータ転送を開始することができます。
2、4回オフTCP
各端子に接続された4回（四wayhandshake）を使用してTCP接続終了ハンドシェイク手順が、独立プロセスで終了することができます。したがって、典型的なプロセスは、各端末の断線をFINとACKのペアを必要とします。
接続は、接続を解放するために変更されたTCP 3ウェイハンドシェイクを使用して確立されてきたために（マークされたセグメントとのFINを使用）。TCPコネクションを閉じるステップは、次のとおりです。
最初の波：クライアントは、クライアントサーバー入札者へのデータ転送を閉じるため、FINを送信し、クライアントがFIN_WAIT_1状態になります。
第二波：サーバは、クライアント、受付番号+1のための確認応答番号を（同じSYN、FINシーケンス番号を占有する）を送信するFIN、ACKを受信すると、サーバーはCLOSE_WAIT状態になります。
第三の波：サーバーはクライアントサーバーのデータ転送を閉じるため、FINを送信し、LAST_ACKサーバーは状態になります。
第四の波：クライアントは、FINを受信し、クライアントは確認応答番号の数+ 1を受信するために、TIME_WAIT状態に入り、その後、サーバにACKを送信し、サーバはCLOSED状態は、4つの完全な波を入射します。
为什么连接的时候是三次握手，关闭的时候却是四次握手？
为什么A还要发送一次确认呢?这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。
所谓已失效的连接请求报文段是这样产生的。A发送连接请求，但因连接请求报文丢失而未收到确认，于是A重发一次连接请求，成功后建立了连接。数据传输完毕后就释放了连接。现在假定A发出的第一个请求报文段并未丢失，而是在某个网络节点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误以为A又发了一次新的连接请求，于是向A发出确认报文段，同意建立连接。假如不采用三次握手，那么只要B发出确认，新的连接就建立了。
由于A并未发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据，因此白白浪费了许多资源。
采用TCP三次握手的方法可以防止上述现象发生。例如在刚才的情况下，由于A不会向B的确认发出确认，连接就不会建立。
如果在TCP第三次握手中的报文段丢失了会发生什么情况?
Client认为这个连接已经建立，如果Client端向Server写数据，Server端将以RST包响应，方能感知到Server的错误。
为什么需要四次挥手
①、为了保证A发送的最后一个ACK报文段能够到达B。即最后这个确认报文段很有可能丢失，那么B会超时重传，然后A再一次确认，同时启动2MSL计时器，如此下去。如果没有等待时间，发送完确认报文段就立即释放连接的话，B就无法重传了（连接已被释放，任何数据都不能出传了），因而也就收不到确认，就无法按照步骤进入CLOSE状态，即必须收到确认才能close。
②、防止“已失效的连接请求报文段”出现在连接中。经过2MSL，那些在这个连接持续的时间内，产生的所有报文段就可以都从网络中消失。即在这个连接释放的过程中会有一些无效的报文段滞留在楼阁结点，但是呢，经过2MSL这些无效报文段就肯定可以发送到目的地，不会滞留在网络中。这样的话，在下一个连接中就不会出现上一个连接遗留下来的请求报文段了。
3、TCP有限状态机
（1）CLOSED 状态时初始状态。
（2）LISTEN:被动打开，服务器端的 状态变为LISTEN(监听).
（3）SYNRECVD:服务器端收到SYN后，状态为）SYNRECVD；发送SYN ACK;
（4）SYN_SENT:客户端发送SYN后，状态为SYN_SENT；
（5）ESTABLISHED:SYNRECVD收到ACK后，状态为ESTABLISHED； SYN_SENT在收到SYN ACK，发送ACK，状态为ESTABLISHED；
（6）CLOSE_WAIT:服务器端在收到FIN后，发送ACK，状态为CLOSE_WAIT；如果此时服务器端还有数据需要发送，那么就发送，直到数据发送完毕；此时，服务器端发送FIN，状态变为LAST_ACK;
（7）FIN_WAIT_1：客户端发送FIN，准备断开TCP连接；状态从ESTABLISHED——>FIN_WAIT_1；
（8）FIN_WAIT_2：应用程序端只收到服务器端得ACK信号，并没有收到FIN信号；说明服务器端还有数据传输，那么此时为半连接；
（9）TIME_WAIT:有两种方式进入 该状态：1、FIN_WAIT_1进入：客户端口收到FIN+ACK（而不是像FIN_WAIT_2那样只收到ACK，说明数据已经发送完毕）并 向服务器端口发送ACK；2、FIN_WAIT_2进入：此时应用程序端口收到了FIN，然后向服务器端发送ACK；TIME_WAIT是为了实现TCP 全双工连接的可靠性关闭，用来重发可能丢失的ACK报文；需要持续2个MSL(最大报文生存时间)：假设应用程序端口在进入TIME_WAIT后，2个 MSL时间内并没有收到FIN,说明应用程序最后发出的ACK已经收到了；否则，会在2个MSL内在此收到ACK报文；
3.1.客户端应用程序的状态迁移图
客户端的状态可以用如下的流程来表示：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
以上流程是在程序正常的情况下应该有的流程，从书中的图中可以看到，在建立连接时，当客户端收到SYN报文的ACK以后，客户端就打开了数据交互地连接。而结束连接则通常是客户端主动结束的，客户端结束应用程序以后，需要经历FIN_WAIT_1，FIN_WAIT_2等状态，这些状态的迁移就是前面提到的结束连接的四次握手。
3.2.服务器的状态迁移图
服务器的状态可以用如下的流程来表示：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
在建立连接的时候，服务器端是在第三次握手之后才进入数据交互状态，而关闭连接则是在关闭连接的第二次握手以后（注意不是第四次）。而关闭以后还要等待客户端给出最后的ACK包才能进入初始的状态。
3.3.其他状态迁移
书中的图还有一些其他的状态迁移，这些状态迁移针对服务器和客户端两方面的总结如下
LISTEN->SYN_SENT，对于这个解释就很简单了，服务器有时候也要打开连接的嘛。
SYN_SENT->SYN收到，服务器和客户端在SYN_SENT状态下如果收到SYN数据报，则都需要发送SYN的ACK数据报并把自己的状态调整到SYN收到状态，准备进入ESTABLISHED
SYN_SENT->CLOSED，在发送超时的情况下，会返回到CLOSED状态。
SYN_收到->LISTEN，如果受到RST包，会返回到LISTEN状态。
SYN_收到->FIN_WAIT_1，这个迁移是说，可以不用到ESTABLISHED状态，而可以直接跳转到FIN_WAIT_1状态并等待关闭。
3.4MSL等待状态
书中给的图里面，有一个TIME_WAIT等待状态，这个状态又叫做2MSL状态，说的是在TIME_WAIT2发送了最后一个ACK数据报以后，要进入TIME_WAIT状态，这个状态是防止最后一次握手的数据报没有传送到对方那里而准备的（注意这不是四次握手，这是第四次握手的保险状态）。这个状态在很大程度上保证了双方都可以正常结束，但是，问题也来了。
由于插口的2MSL状态（插口是IP和端口对的意思，socket），使得应用程序在2MSL时间内是无法再次使用同一个插口的，对于客户程序还好一些，但是对于服务程序，例如httpd，它总是要使用同一个端口来进行服务，而在2MSL时间内，启动httpd就会出现错误（插口被使用）。为了避免这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然可以重新启动服务器，但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。
3.5.FIN_WAIT_2状态
这就是著名的半关闭的状态了，这是在关闭连接时，客户端和服务器两次握手之后的状态。在这个状态下，应用程序还有接受数据的能力，但是已经无法发送数据，但是也有一种可能是，客户端一直处于FIN_WAIT_2状态，而服务器则一直处于WAIT_CLOSE状态，而直到应用层来决定关闭这个状态。
3.6.RST，同时打开和同时关闭
RST是另一种关闭连接的方式，应用程序应该可以判断RST包的真实性，即是否为异常中止。而同时打开和同时关闭则是两种特殊的TCP状态，发生的概率很小。