1.数据包说明
1）源端口号（16位）：它（连同源主机IP地址）标识源主机的一个应用进程。
2）目标端口号（16位）：它（连同源主机IP地址）标识目的主机的一个应用进程。这两个值加上IP报头中的源主机IP地址和目的主机IP地址唯一确定一个TCP连接。
3）顺序号 seq（32位）：用来标识从TCP源端向TCP目标端发送的数据字节流，它表示在这个报文段中第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则TCP用顺序号对每个字节进行计数。序号是32bit的无符号数，序号到达2的32次方-1后又从0开始。当建立一个新的链接时，SYN标志变1，顺序号字段包含由这个主机选择的该连接的初始顺序号ISN
4）确认号 ack（32位）：包含发送的一端所期望收到的下一顺序号。因此，确认序号应当是上次已成功收到数据字节顺序号+1。只有ACK标志为1时，确认号字段才有效。TCP为应用层提供全双工服务，这意味数据能在两个方向上独立的进行传输。因此，连接的每一端必须保持每个方向上的传输数据顺序号。
5）TCP报文长度（4位）：给出报头中32bit字的数目，它实际上指明数据从哪里开始。需要这个值是因为任选字段的长度是可变的。这个字段占4bit，因此TCP最多有60字节的首部。然而，没有任选字段，正常的长度为20字节。
6）保留位（6位）：保留给将来使用，目前必须置为0。
7）控制位（6位）：在TCP报头中有6个标志比特，他们中多个可同时被设置为1。依次为：
URG：为1表示紧急指针有效，为0则忽略紧急指针值。
ACK：为1表示确认号有效，为0表示报文中不包含确认信息，忽略确认号字段。
PSH：为1表示是带有PUSH标志的数据，指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满。
RST：用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报文段和拒绝连接请求。一般情况下，如果收到一个RST为1的报文，那么一定发生了某些问题。
SYN：同步序号，为1表示连接请求，用于建立连接和使顺序号同步（synchronize）。
FIN：用于释放连接，为1表示发送方已经没有数据发送了，即关闭本方数据流。
8）窗口大小（16位）：数据字节数，表示从确认号开始，本报文的源方可以接收的字节数，即源方接收窗口大小。窗口大小是一个16bit字段，因而窗口大小最大为65535字节。
9）校验和（16位）：此校验和是对整个的TCP报文段，包括TCP头部和TCP数据，以16位字进行计算所得。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。
10）紧急指针（16位）：只有当URG标志置1时紧急指针才有效。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。
11）选项：最常见的可选字段是最长报文大小，又称为MSS。每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志的那个段）中指明这个选项，它指明本端所能接收的最大长度的报文段。选项长度不一定是32位字的整数倍，所以要加填充位，使得报头长度成为整字数。
12）数据：TCP报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有TCP首部。如果一方没有数据发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。
2.客户端与服务器间的通信
三次握手：
第一次握手：建立连接。客户端发送连接请求报文段，将位码SYN设置为1，seq为x；然后客户端进入SYN_SEND状态，等待服务器的确认；
第二次握手：服务器收到客户端的SYN报文段，并对这个SYN报文段进行确认，设置ACK为x+1（即收到的seq+1）；同时自己还要发送SYN请求信息，将SYN设置为1、seq为y；服务器端将所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态。
第三次握手：客户端收到服务器的SYN+ACK报文段后将ACK设置为y+1，seq为z，向服务器发送ACK报文段，这个报文段发送完后，客户端和服务器都进入确认状态，完成三次握手。
为什么要三次握手？答：三次握手的目的是建立可靠的通信通道。
四次挥手：
第一次挥手：首先客户端发送一个FIN，用来关闭客户端到服务器的数据传送，然后等待服务器的确认。其终止标志位FIN=1，序列号seq=x；
第二次挥手：服务端收到这个FIN后，它会发回一个ACK给客户端，确认号ACK为收到的序号seq+1，服务端进入CLOSE_WAIT状态；
第三次挥手：服务器数据传送完成后，会发送一个FIN给客户端，用来关闭服务端到客户端的数据传送，其终止标志位FIN=1，序列号seq=y，服务端进入LAST_ACK状态；
第四次挥手：客户端收到FIN后，客户端进入TIME_WAIT状态，并发回一个ACK报文确认，确认序号seq为收到的序号加1，服务端进入关闭状态，完成四次挥手。
1、TCP建立连接要进行三次握手，而断开连接要进行四次？
这是由于TCP的半关闭造成的。因为TCP连接是全双工的（即数据可在两个方向上同时传递），所以进行关闭时每个方向上都要单独进行关闭。这个单方向的关闭就叫半关闭。当一方完成它的数据发送任务，就发送一个FIN来向另一方通告将要终止这个方向的连接。
2、为什么收到Server端的确认之后，Client还需要进行第三次“握手”呢？
采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。
“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络节点长时间的滞留了（因为网络并发量很大在某节点被阻塞了），以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误以为是client再次发出的一个新的连接请求。于是就行client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的链接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却认为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。主要目的防止server端一直等待，浪费资源。
如果两次握手的话，客户端有可能因为网络阻塞等原因会发送多个请求报文，这是服务器就会建立连接，浪费掉许多服务器的资源。
3、为什么要四次挥手？
确保数据能够完成传输。
但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上关闭SOCKET，也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
TCP协议是一个面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。
4、建立连接的第二个SYN作用是啥？
因为客户端发送的syn可能过了好久才到达服务端，而此时客户端超时重传的SYN已经到达服务端，那么后来的SYN就是无效的，如果不发第二个syn查询客户端是否有效的话，服务端就会监听这个延迟到达的请求，造成资源的浪费。所以可以强制发送一个SYN询问客户端之前的请求是否有效。
5、time_wait状态产生的原因？
1）可靠地实现TCP全双工连接的终止
我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，client必须维护这条连接的状态（保持time_wait，具体而言，就是这条TCP连接对应的(local_ip,local_port)资源不能被立即释放或重新分配）以便可以重发丢失的ACK，如果主动关闭端不维持TIME_WAIT状态，而是出于CLOSE状态，主动关闭端将会响应一个RST，结果server认为发生错误，导致服务器不能正常关闭连接。所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。所以，当客户端等待2MSL（2倍报文最大生存时间）后没有收到服务器的FIN报文后，它就知道服务端已收到了ACK报文，所以客户端此时才关闭自己的连接。
2）允许老的重复分节在网络中消逝
第二，防止上一节提到的“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以试下一个新的连接中不会出现这种旧的连接请求报文段。
如果TIME_WAIT状态保持时间不够长（比如小于2MSL），第一个连接就正常终止了。第二个拥有相同四元组（local_ip,local_port,remote_ip,remote_port）的连接出现（建立起一个相同IP地址和端口之间的TCP连接），而第一个连接的重复报文到达，干扰了第二个连接。TCP实现必须防止某个连接的重复报文在连接终止后出现，所以让TIME_WAIT状态保持时间足够长（2MSL），连接相应方向上的TCP报文要么完全响应完毕，要么被丢弃。建立第二个连续的时候，不会混淆。
6、如果网络连接中出现大量TIME_WAIT状态所带来的危害？
如果系统中有很多socket处于TIME_WAIT状态，当需要创建新的socket连接时可能会受到影响，这也会影响到系统的扩展性。
之所以TIME_WAIT能够影响系统的扩展性是因为在一个TCP连接中，一个socket如果关闭的话，它将保持TIME_WAIT状态大约1-4分钟。如果很多连接快速的打开和关闭的话，系统中处于TIME_WAIT状态的socket将会积累很多，由于本地端口数量的限制，同一时间只有有限数量的socket链接可以建立，如果太多的socket处于TIME_WAIT状态，你会发现，由于用于新建连接的本地端口太缺乏，将会很难再建立新的对外连接。
7、如何消除大量TCP短连接引发的TIME_WAIT？
1）可以改为长连接，但代价较大，长连接太多会导致服务器性能问题，而且PHP等脚本语言，需要通过proxy之类的软件才能实现长连接；
2）修改ipv4.ip_local_port_range，增大可用端口范围，但只能缓解问题，不能根本解决问题；
3）客户端程序中设置socket的SO_LINGER选项；
4）客户端机器打开tcp_tw_recycle和tcp_timestamps选项；
5）客户端机器打开tcp_tw_reuse和tcp_timestamps选项；
6）客户端机器设置tcp_max_tw_buckets为一个很小的值；
8、TIME_WAIT的时间？
就是2个报文最长生存时间（2MSL），1个MSL在RFC上建议是2分钟，而实现传统上使用30秒，因而，TIME_WAIT状态一般维持在1-4分钟。
9、当关闭连接最后一个ACK丢失怎么办？
如果最后一个ACK丢失的话，TCP就会认为它的FIN丢失，进行重发FIN。在客户端收到FIN后，就会设置一个2MSL计时器，2MSL计时器可以使客户等待足够长的时间，使得在ACK丢失的情况下，可以等待下一个FIN的到来。如果在TIME_WAIT状态内有一个新的FIN到达了，客户就会发送一个新的ACK，并重新设置2MSL计时器。
如果重传FIN到达客户端时，客户端已经进入CLOSED状态时，那么客户就永远收不到这个重传的FIN报文段，服务器收不到ACK，服务器无法关闭连接。
10、TCP建立连接之后怎么保持连接（检测连接断没断）？
有两种技术可以运用。一种是有TCP协议层实现的Keepalive机制，另一种是由应用层自己实现的HeartBeat心跳包。
1）在TCP中有一个Keep-alive的机制可以检测死连接，原理很简单，当连接闲置一定的时间（参数值可以设置，默认是2个小时）之后，TCP协议会向对方发一个keepalive探针包（包内没有数据），对方在收到包以后，如果连接一切正常，则应当回复一个ACK；如果连接出现错误了（例如对方重启了，连接状态丢失），则应当回复一个RST；如果对方没有回复，那么，服务器每隔一定的时间（参数值可以设置）再发送keepalive探针包，如果连续多个包（参数值可以设置）都被无视了，说明连接被断开了。
2）心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。由应用程序自己发送心跳包来检测连接的健康性。客户端可以在一个Timer中或低级别的线程中定时向服务器发送一个短小精悍的包，并等待服务器的回应。客户端程序在一定时间内没有收到服务器回应即认为连接不可用，同样，服务器在一定时间内没有收到客户端的心跳包则认为客户端已经掉线。