【Java TCP/IP Socket编程】----深入剖析----TCP数据传输中的死锁和性能

目录

 

死锁问题

数据传输性能

案例

---

--------笔记来自于书籍《Java TCP/IP Socket编程》

死锁问题

在TCP数据传输底层实现中（详细参见https://blog.csdn.net/lili13897741554/article/details/83104539）可能会出现死锁的情况，因此程序协议必须设计得非常小心，避免死锁的发生。以下情况可能导致死锁：

1.每个对等端都在阻塞等待其他端完成一些工作，例如：如果在连接建立后，客户端和服务器端都立即尝试接收数据，显然将导致死锁。

2.SendQ和RecvQ缓冲区的容量在具体实现时会收到一定的限制，如果与TCP的流向控制机制结合使用，有可能到产生死锁的情况。

1）详细说明：

      虽然SendQ和RecvQ缓冲区容量使用的实际大小会动态地增大和收缩，还是需要一个硬性限制，防止行为异常的程序所控制的单独一个TCP连接将系统的内存全部耗尽，由于这些缓冲区的容量有限，它们可能被填满。一旦RecvQ已满，TCP流控制机制就会产生作用。它将阻止传输发送端主机的SendQ中的任何数据，直到接收者调用输入流的read()方法后腾出空间。（使用流控制机制的目的就是为了保证发送者不会传输太多数据，而超出了接收系统的处理能力。）发送程序可以持续地写出数据，直到SendQ队列被填满，然而，如果SendQ队列已满时调用out.write()方法，则将阻塞等待，直到有新的空间为止，也就是说直到一些字节传输到了接收到套接字的RecvQ队列中。如果此时RecvQ队列也已经被填满，所有操作都将停止，直到接收程序调用in.read()方法将一些字节传输到Delivered队列中。

    假设SendQ队列和RecvQ队列大小分别是SQS和RQS。将一个大小为n的字节数组传递给write()方法调用，其中n>SQS，直到有至少n-SQS字节传递到接收端主机的RecvQ对列后，该方法才会返回。如果n大小超过了（SQS+RQS）,write()方法则将在接收程序从输入流中读取了n-(SQS+RQS)字节后才会返回。如果接收程序没有调用read()方法，大数量的send()调用则无法成功。特别是当连接的两端同时分别调用它们输出流的write()方法，而它们的缓冲区大小又大于SQS+RQS时将发生死锁，两个write操作都不能完成，两个程序都将永远保持阻塞状态。

2）具体实例：

     主机A上的程序和主机B上的程序之间有一个连接，假设A和B上的SQS和RQS都是500字节，两个程序试图同时发送1500字节时的情况。