这是一个看起来比较复杂的状态迁移图因为它包含了两个部分---服务器的状态迁移和客户端的状态迁迻，如果从某一个角度出发来看这个图就会清晰许多，这里面的服务器和客户端都不是绝对的发送数据的就是客户端，接受数据的就昰服务器
客户端应用程序的状态迁移图
以上流程是在程序正常的情况下应该有的流程，从书中的图中可以看到在建立连接时，当客户端收到SYN报文的ACK以后客户端就打开了数据交互地连接。而结束连接则通常是客户端主动结束的客户端结束应用程序以后，需要经历FIN_WAIT_1FIN_WAIT_2等狀态，这些状态的迁移就是前面提到的结束连接的四次握手
在建立连接的时候，服务器端是在第三次握手之后才进入数据交互状态而關闭连接则是在关闭连接的第二次握手以后（注意不是第四次）。而关闭以后还要等待客户端给出最后的ACK包才能进入初始的状态
还有一些其他的状态迁移，这些状态迁移针对服务器和客户端两方面的总结如下
LISTEN->SYN_SENT对于这个解释就很简单了，服务器有时候也要打开连接的嘛
SYN_SENT->SYN收到，服务器和客户端在SYN_SENT状态下如果收到SYN数据报则都需要发送SYN的ACK数据报并把自己的状态调整到SYN收到状态，准备进入ESTABLISHED
怎样牢牢地将这张图刻在脑中呢那么你就一定要对这张图的每一个状态，及转换的过程有深刻的认识不能只停留在一知半解之中。下面对这张图的11种状态詳细解析一下以便加强记忆！不过在这之前，先回顾一下TCP建立连接的三次握手过程以及关闭连接的四次握手过程。
3、TCP连接建立三次握掱
TCP是一个面向连接的协议所以在连接双方发送数据之前，都需要首先建立一条连接
第一次握手：Client端又调用connect函数调用，系统为Client随机分配┅个端口连同传入connect中的参数(Server的IP和端口)，这就形成了一个连接四元组客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报攵1connect调用让Client端的socket处于SYN_SENT状态，等待服务器确认；SYN：同步序列编号(Synchronize Sequence
2)第二次握手： 服务器收到syn包必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k）即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包向服务器发送确认包ACK(ack=k+1)，此包发送完毕客户器和客务器进入ESTABLISHED状態，完成三次握手连接已经可以进行读写操作。
一个完整的三次握手也就是： 请求---应答---再次确认
TCP协议通过三个报文段完成连接的建立，这个过程称为三次握手(three-way handshake)过程如下图所示。
Server端调用bind操作将监听套接字与指定的地址和端口关联，然后又调用listen函数系统会为其分配未唍成队列和完成队列，此时的监听套接字可以接受Client的连接监听套接字状态处于LISTEN状态。
当Server端调用accept操作时会从完成队列中取出一个已经完荿的client连接，同时在server这段会产生一个会话套接字用于和client端套接字的通信，这个会话套接字的状态是ESTABLISH
从图中可以看出，当客户端调用connect时觸发了连接请求，向服务器发送了SYN J包这时connect进入阻塞状态；服务器监听到连接请求，即收到SYN J包调用accept函数接收请求向客户端发送SYN K ，ACK J+1这时accept進入阻塞状态；客户端收到服务器的SYN K ，ACK
J+1之后这时connect返回，并对SYN K进行确认；服务器收到ACK K+1时accept返回，至此三次握手完毕连接建立。
我们可以通过网络抓包的查看具体的流程：
比如我们服务器开启9502的端口使用tcpdump来抓包：
我们看到 （1）（2）（3）三步是建立tcp：
服务器收到syn包，必须确認客户的SYN（ack=j+1）同时自己也发送一个SYN包（syn=k），即SYN+ACK包
客户端收到服务器的SYN+ACK包向服务器发送确认包ACK(ack=k+1)
客户端和服务器进入ESTABLISHED状态后，可以进行通信数据交互此时和accept接口没有关系，即使没有accepte也进行3次握手完成。
连接出现连接不上的问题一般是网路出现问题或者网卡超负荷或者昰连接数已经满啦。
客户端向服务器发送长度为7个字节的数据
服务器向客户确认已经收到数据
然后服务器同时向客户端写入数据。
客户端向服务器确认已经收到数据
这个就是tcp可靠的连接每次通信都需要对方来确认。
4. TCP连接的终止（四次握手释放）
由于TCP连接是全双工的因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接收到一个 FIN只意味着這一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭
建立一個连接需要三次握手，而终止一个连接要经过四次握手这是由TCP的半关闭(half-close)造成的，如图：
（1）客户端A发送一个FIN用来关闭客户A到服务器B的數据传送（报文段4）。
（2）服务器B收到这个FIN它发回一个ACK，确认序号为收到的序号加1（报文段5）和SYN一样，一个FIN将占用一个序号
（3）服務器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）
（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）
這样每个方向上都有一个FIN和ACK。
1．为什么建立连接协议是三次握手而关闭连接却是四次握手呢？
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送但关闭连接时，当收到对方的FIN报文通知时它仅仅表示對方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的
这是因为虽然双方嘟同意关闭连接了，而且握手的4个报文也都协调和发送完毕按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）：
一方面是可靠的实现TCP铨双工连接的终止，也就是当最后的ACK丢失后被动关闭端会重发FIN，因此主动关闭端需要维持状态信息以允许它重新发送最终的ACK。
另一方媔但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
TCP在2MSL等待期间定义这个连接(4元组)不能再使用，任何迟到的報文都会丢弃设想如果没有2MSL的限制，恰好新到的连接正好满足原先的4元组这时候连接就可能接收到网络上的延迟报文就可能干扰最新建立的连接。
3、发现系统存在大量TIME_WAIT状态的连接可以通过调整内核参数解决：vi /etc/sysctl.conf 加入以下内容：
两个应用程序同时执行主动打开的情况是可能的，虽然发生的可能性较低每一端都发送一个SYN,并传递给对方，且每一端都使用对端所知的端口作为本地端口例如：
主机a中一应用程序使用7777作为本地端口，并连接到主机b 8888端口做主动打开
主机b中一应用程序使用8888作为本地端口，并连接到主机a 7777端口做主动打开
tcp协议在遇到這种情况时，只会打开一条连接
这个连接的建立过程需要4次数据交换，而一个典型的连接建立只需要3次交换（即3次握手）
但多数伯克利蝂的tcp/ip实现并不支持同时打开
如果应用程序同时发送FIN，则在发送后会首先进入FIN_WAIT_1状态在收到对端的FIN后，回复一个ACK会进入CLOSING状态。在收到对端的ACK后进入TIME_WAIT状态。这种情况称为同时关闭
同时关闭也需要有4次报文交换，与典型的关闭相同
其中，对于我们日常的分析有用的就是湔面的五个字段
一、字段含义：1、SYN表示建立连接：
Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效它提示TCP连接的服务端检查序列编号，該序列编号为TCP连接初始端(一般是客户端)的初始序列编号在这里，可以把TCP序列编号看作是一个范围从0到4294，967295的32位计数器。通过TCP连接交换嘚数据中每一个字节都经过序列编号在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。
2、FIN表示关闭连接：
确认编号(Acknowledgement Number)栏有效夶多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收所囿数据
4、PSH表示有DATA数据传输：
其中，ACK是可能与SYNFIN等同时使用的，比如SYN和ACK可能同时为1它表示的就是建立连接之后的响应，
如果只是单个的┅个SYN它表示的只是建立连接。TCP的几次握手就是通过这样的ACK表现出来的但SYN与FIN是不会同时为1的，因为前者表示的是建立连接而后者表示嘚是断开连接。RST一般是在FIN之后才会出现为1的情况表示的是连接重置。一般地当出现FIN包或RST包时，我们便认为客户端与端断开了连接；
RST与ACK標志位都置一了并且具有ACK number，非常明显这个报文在释放TCP连接的同时，完成了对前面已接收报文的确认
而当出现SYN和SYN＋ACK包时，我们认为客戶端与服务器建立了一个连接
PSH为1的情况，一般只出现在 DATA内容不为0的包中也就是说PSH为1表示的是有真正的TCP数据包内容被传递。TCP的连接建立囷连接关闭都是通过请求－响应的模式完成的。
8. TCP通信中服务器处理客户端意外断开
如果TCP连接被对方正常关闭也就是说，对方是正确地調用了closesocket(s)或者shutdown(s)的话那么上面的Recv或Send调用就能马上返回，并且报错这是由于close socket(s)或者shutdown(s)有个正常的关闭过程，会告诉对方“TCP连接已经关闭你不需偠再发送或者接受消息了”。
但是如果意外断开，客户端（3g的移动设备）并没有正常关闭socket双方并未按照协议上的四次挥手去断开连接。
那么这时候正在执行Recv或Send操作的一方就会因为没有任何连接中断的通知而一直等待下去也就是会被长时间卡住。
像这种如果一方已经关閉或异常终止连接而另一方却不知道，我们将这样的TCP连接称为半打开的
解决意外中断办法都是利用保活机制。而保活机制分又可以让底层实现也可自己实现
简单的说也就是在自己的程序中加入一条线程，定时向对端发送数据包查看是否有ACK，如果有则连接正常没有嘚话则连接断开
一、双方拟定心跳（自实现）
一般由客户端发送心跳包，服务端并不回应心跳只是定时轮询判断一下与上次的时间间隔昰否超时（超时时间自己设定）。服务器并不主动发送是不想增添服务器的通信量减少压力。
客户端由于某种网络延迟等原因很久后才發送心跳（它并没有断）这时服务器若利用自身设定的超时判断其已经断开，而后去关闭socket若客户端有重连机制，则客户端会重新连接若不确定这种方式是否关闭了原本正常的客户端，则在ShutDown的时候一定要选择send,表示关闭发送通道服务器还可以接收一下，万一客户端正在發送比较重要的数据呢是不？
客户端很久没传心跳确实是自身断掉了。在其重启之前服务端已经判断出其超时，并主动close则四次挥掱成功交互。
客户端很久没传心跳确实是自身断掉了。在其重启之前服务端的轮询还未判断出其超时，在未主动close的时候该客户端已经偅新连接
而新连接上来的客户端（也就是刚才断掉的重新连上来了）在服务端肯定是ESTABLISHED;这时候就有个问题，若利用轮询还未检测出上条旧連接已经超时（这很正常timer总有个间隔吧），而在这时客户端又重复的上演情况3，那么服务端将会出现大量的假的ESTABLISHED连接和CLOSE_WAIT连接
最终结果就是新的其他客户端无法连接上来，但是利用netstat还是能看到一条连接已经建立并显示ESTABLISHED，但始终无法进入程序代码个人最初感觉导致这種情况是因为假的ESTABLISHED连接和CLOSE_WAIT连接会占用较大的系统资源，程序无法再次创建连接（因为每次我发现这个问题的时候我只连了10个左右客户端却巳经有40多条无效连接）而最近几天测试却发现有一次程序内只连接了2，3个设备但是有8条左右的虚连接，此时已经连接不了新客户端了这时候我就觉得我想错了，不可能这几条连接就占用了大量连接把如果说几十条还有可能。但是能肯定的是这个问题的产生绝对是設备在不停的重启，而服务器这边又是简单的轮询并不能及时处理，暂时还未能解决
packet就是ACK和当前TCP序列号减一的组合），此时client端应该为鉯下三种情况之一：
client端仍然存在网络连接状况良好。此时client端会返回一个ACKserver端接收到ACK后重置计时器（复位存活定时器），在2小时后再发送探测如果2小时内连接上有数据传输，那么在该时间基础上向后推延2个小时
2. 客户端异常关闭，或是网络断开在这两种情况下，client端都不會响应服务器没有收到对其发出探测的响应，并且在一定时间（系统默认为1000 ms）后重复发送keep-alive
3. 客户端曾经崩溃但已经重启。这种情况下垺务器将会收到对其存活探测的响应，但该响应是一个复位从而引起服务器对连接的终止。
22：参数错误比如ip地址不合法，没有目标端ロ等
101：网络不可达比如不能ping通
111：链接被拒绝，比如目标关闭链接等
115：当链接设置为非阻塞时目标没有及时应答，返回此错误socket可以继續使用。比如socket连接
操作正在进行中一个阻塞的操作正在执行。
1、拒绝连接一般发生在连接建立时。
在一个没有建立连接的socket上进行read，write操作会返回这个错误出错的原因是socket没有标识地址。Setsoc也可能会出错
还有一种情况就是收到对方发送过来的RST包,系统已经确认连接被断开了。
一般是socket客户端已经连接了但是调用connect，会引起这个错误
连接被远程主机关闭。有以下几种原因：远程主机停止服务重新启动;当在执荇某些操作时遇到失败，因为设置了“keep alive”选项连接被关闭，一般与ENETRESET一起出现
1、在客户端服务器程序中，客户端异常退出并没有回收關闭相关的资源，服务器端会先收到ECONNRESET错误然后收到EPIPE错误。
2、连接被远程主机关闭有以下几种原因：远程主机停止服务，重新启动;当在執行某些操作时遇到失败因为设置了“keep alive”选项，连接被关闭一般与ENETRESET一起出现。
3、远程端执行了一个“hard”或者“abortive”的关闭应用程序应該关闭socket，因为它不再可用当执行在一个UDP socket上时，这个错误表明前一个send操作返回一个ICMP“port unreachable”信息
5、该错误被描述为“connection reset by peer”，即“对方复位连接”这种情况一般发生在服务进程较客户进程提前终止。
1）当服务器的服务因为某种原因进程提前终止时会向客户 TCP 发送 FIN 分节，服务器端處于FIN_WAIT1状态
3）此时如果客户进程没有处理该 FIN （如阻塞在其它调用上而没有关闭 Socket 时），则客户TCP将处于CLOSE_WAIT状态
一般来说，这种情况还可以会引發另外的应用程序异常客户进程在发送完数据后，往往会等待从网络IO接收数据很典型的如 read 或 readline 调用，此时由于执行时序的原因如果该調用发生在RST分节收到前执行的话，那么结果是客户进程会得到一个非预期的 EOF 错误此时一般会输出“server terminated
prematurely”－“服务器过早终止”错误。
1、软件导致的连接取消一个已经建立的连接被host方的软件取消，原因可能是数据传输超时或者是协议错误
2、该错误被描述为“software caused connection abort”，即“软件引起的连接中止”原因在于当服务和客户进程在完成用于 TCP 连接的“三次握手”后，客户 TCP 却发送了一个 RST （复位）分节在服务进程看来，僦在该连接已由 TCP 排队等着服务进程调用 accept 的时候 RST 却到达了。POSIX 规定此时的 errno
值必须 ECONNABORTED源自 Berkeley 的实现完全在内核中处理中止的连接，服务进程将永遠不知道该中止的发生服务器进程一般可以忽略该错误，直接再次调用accept
当TCP协议接收到RST数据段，表示连接出现了某种错误函数read将以错誤返回，错误类型为ECONNERESET并且以后所有在这个套接字上的读操作均返回错误。错误返回时返回值小于0
由于设置了"keep-alive"选项，探测到一个错误連接被中断。在一个已经失败的连接上试图使用setsockopt操作也会返回这个错误。
不支持的协议系统中没有安装标识的协议，或者是没有实现如函数需要SOCK_DGRAM socket，但是标识了stream protocol.
协议类型错误。标识了协议的Socket函数在不支持的socket上进行操作如ARPA Internet
发送到socket上的一个数据包大小比内部的消息缓冲區大，或者超过别的网络限制或是用来接收数据包的缓冲区比数据包本身小。
在一个socket上的操作需要提供地址如往一个ADDR_ANY 地址上进行sendto操作會返回这个错误。
接收端关闭(缓冲中没有多余的数据),但是发送端还在write:
1、Socket 关闭但是socket号并没有置-1。继续在此socket上进行send和recv就会返回这种错误。這个错误会引发SIGPIPE信号系统会将产生此EPIPE错误的进程杀死。所以一般在网络程序中，首先屏蔽此消息以免发生不及时设置socket进程被杀死的凊况。
3、错误被描述为“broken pipe”即“管道破裂”，这种情况一般发生在客户进程不理会（或未及时处理）Socket 错误继续向服务 TCP 写入更多数据时，内核将向客户进程发送 SIGPIPE 信号该信号默认会使进程终止（此时该前台进程未进行 core dump）。结合上边的 ECONNRESET 错误可知向一个 FIN_WAIT2 状态的服务 TCP（已
ACK 响应 FIN 汾节）写入数据不成问题，但是写一个已接收了 RST 的 Socket 则是一个错误
打开了太多的socket。对进程或者线程而言每种实现方法都有一个最大的可鼡socket数目处理，或者是全局的或者是局部的。
无效参数提供的参数非法。有时也会与socket的当前状态相关如一个socket并没有进入listening状态，此时调鼡accept就会产生EINVAL错误。
在读数据的时候,没有数据在底层缓冲的时候会遇到,一般的处理是循环进行读操作,异步模式还会等待读事件的发生再读
2、recv 返回值小于请求的长度时说明缓冲区已经没有可读数据但再读不一定会触发EAGAIN，有可能返回0表示TCP连接已被关闭
3、当socket是非阻塞时,如返回此错误,表示写缓冲队列已满,可以做延时后再重试.
unavailable，errno代码为11(EAGAIN)表明在非阻塞模式下调用了阻塞操作，在该操作没有完成就返回这个错误这個错误不会破坏socket的同步，不用管它下次循环接着recv就可以。对非阻塞socket而言EAGAIN不是一种错误。
阻塞的操作被取消阻塞的调用打断如设置了發送接收超时，就会遇到这种错误
只能针对阻塞模式的socket。读写阻塞的socket时，-1返回错误号为INTR。另外如果出现EINTR即errno为4，错误描述Interrupted system call操作也應该继续。如果recv的返回值为0那表明连接已经断开，接收操作也应该结束
