正如文章所说，正常情况大家都不会去关注其协议细节，但在网络不稳定或嵌入式设备上没有完毕的TCP/IP协议像LINUX那样提供安全可靠保证，相关的网络问题就会变得很复杂。
- 客户端试图与一个不存在的端口建立连接（主机正常）
客户端的SYNC包到达服务端时，返回一个RST的错误报文。TCP的服务端实际上就是从网卡的寄存器中读取数据，然后进行解析（端口的套接字）。
- 建立链接后服务器的主机发送了宕机：
此时客户端并不知道，根据场景又分为刚宕机和宕机一段时间。
刚宕机：客户端会每隔一段时间重发SYN包。
宕机好一段时间：
- 建立链接后服务器的主机僵死（内核，应用程序线程：
服务端通过accept接口返回一个新的套接字，说明3次握手完成了可以建立连接，否则accept会被阻塞。accept本质：它会通过软中断陷入内核中，最终会调用tcp协议的inet_csk_accept函数，该函数会从队列中查找是否有处于ESTABLISHED状态的套接字。如果有则返回该套接字，否则阻塞当前进程。也就是说这里只是一个查询的过程，并不参与三次握手的任何逻辑。
- 客户端在TCP Server的进程/线程crash时访问：
此时客户端会收到RST报文。
- TCP Server的进程/线程被KILL时：
此时服务器端会发出FIN报文,其实kill进程是通过shell想内核发送了SIGKILL或者SIGTERM，内核接收到该信号之后会进行相应的扫尾工作.
- TCP Server的进程/线程所在主机关机：
init进程会给所有进程发送SIGTERM信号，等待一段时间（5~20秒），然后再给所有仍在运行的进程发送SIGKILL信号。当服务器进程死掉时，会关闭所有文件描述符。带来的影响和上面杀死server相同
TCP Server的进程/线程所在主机宕机：
包括2种情况，一种是内核panic，另外一种情况是出现了掉电。
panic：突然性，没有时间杀死进程和关闭所有打开的文件描述符，此时客户端发送请求因为得不到ACK会重复发送企图得到ACK(大约持续几分钟），直到得到一个ETIMDOUT错误。对同步通讯这会导致阻塞而不能接受。虽然通过设置SO_SNDTIMEO，服务器端要做去重处理。
- 客户端在TCP Server的关闭->重启间发送分节内容：
因为TCP Server丢失了之前的连接信息，即此时收到了一个不存在的链接上，所以会响应RST分节。