17 | TCP并不总是“可靠”的？

看到后面我好像理解了我上面那个提问,当崩溃重启过后是重新三次握手建立连接,创建新的套接字,只是在网络上传输的包,因为是通过ip地址和端口方式进行的寻址,所以新连接上去的客户端会接收到之前还没接收到的包,然后新连接的客户端没有这些包的tcp分组信息所以就会给服务器端(对端)发送一个RST

最后的例子没有触发SIGPIPE，是因为老师例子设计的有点儿瑕疵。client 在不断的发送数据，server 则每次接受数据之后都 sleep 一会，也就导致接收速度小于发送速度，进而导致 server 终止的时候接收缓冲区还有数据没有被读取，server 终止触发 close 调用，close 调用时如果接收缓冲区有尚未被应用程序读取的数据时，不发 FIN 包，直接发 RST 包。client 每次发送数据之后 sleep 2秒，再试就会出SIGPIPE 了。

我的电脑，结果也是一样的， 第二个问题，服务器正常关闭，客户端应该是受到了fin包，read返回eOF,wirte返回rst

没有理解 reset by peer 和 broken pipe 的区别。。

>>"但是，发送端并无法获取对应数据流的 ACK 情况" 对上面这段话不理解，TCP 的 ACK不是带着序号的吗？发送端根据这个序号能计算出是哪次发送的ACK。 哪位大牛能解释一下吗？

老师，你文章的案例默认fd都是阻塞的吧，如果是非阻塞的话，返回的n < 0 不一定是错误啊

error(1, 0, "usage: reliable_client01 <IPaddress>");这个error函数，具体是什么作用？

老师 我提一个read直接感知FIN包的疑问哈: 我停留在 stdin这里 等我输入完之后，就能调用read感知到对端已经关闭了呀？ 是因为等到stdin之后，再感知是不是太晚了呀？

第二题 客户端--------服务器 1.  客户端发送FIN包，处于发送缓冲区的数据会逐一发送（可能通过一次或多次write操作发送），FIN包处于这段数据的末尾，当数据到达接收端的接收缓冲区时，FIN起到了一个结束符的作用，当接收端接收数据时遇到FIN包，read操作返回EOF通知应用层。然后接收端返回一个ACK表示对这次发送的确认。（此时客户端进入FIN_WAIT1，服务端进入CLOSE_WAIT状态） 2.  客户端接收到ACK之后，关闭自己的发送通道，客户端此时处于半关闭状态。等待服务器发送FIN包。   (客户端进入FIN_WAIT2状态) 3.  服务端发送FIN包，同上类似处于发送缓冲区的内容会连同FIN包一起发过去，当客户端接收成功后同时将FIN解析为EOF信号使得上层调用返回。（客户端进入TIME_WAIT状态 服务端进入LAST_ACK状态） 4. 客户端等待2MSL的时间，在此期间向服务器发送ACK。如果丢包进行重传。如果服务器收到ACK后 服务器进入CLOSED状态 客户端也进入CLOSED状态。 5. 连接关闭 我想问一下 如果最后一次挥手一直丢包 在2MSL的时间内都没到 TCP会咋办 会重置计时器么 还是就不管了直接关闭呢

# uname -a Linux tst 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux # # ./reliable_client01 127.0.0.1 good peer connection closed # # ./reliable_client01 127.0.0.1 bad bad bad2 peer connection closed # # ./reliable_client02 127.0.0.1 send into buffer 19 send into buffer -1 send error: Connection reset by peer (104)