Socket剖析

最新推荐文章于 2022-07-01 17:27:58 发布

zero__007

最新推荐文章于 2022-07-01 17:27:58 发布

阅读量500

点赞数

分类专栏：网络通信

网络通信专栏收录该内容

11 篇文章 0 订阅

订阅专栏

转载自：http://blog.csdn.net/ns_code/article/details/15813809
http://blog.csdn.net/ns_code/article/details/15939993
http://blog.csdn.net/ns_code/article/details/16113083

Socket数据结构

Socket套接字所关联的底层的数据结构集包含了特定Socket实例所关联的信息。套接字结构除其他信息外还包含：

1、该套接字所关联的本地和远程互联网地址和端口号。
2、一个FIFO（First Im First Out）队列，用于存放接收到的等待分配的数据，以及一个用于存放等待传输的数据的队列。
3、对于TCP套接字，还包含了与打开和关闭TCP握手相关的额定协议状态信息。

了解这些数据结构，以及底层协议如何对其进行影响是非常有用的，因为它们控制了各种Socket对象行为的各个方面。例如，由于TCP提供了一种可信赖的字节流服务，任何写入Socket和OutputStream的数据副本都必须保留，直到连接的另一端将这些数据成功接收。向输出流写数据并不意味着数据实际上已经被发送——它们只是被复制到了本地缓冲区，就算在Socket的OutputStream上进行flush（）操作，也不能保证数据能够立即发送到信道。此外，字节流服务的自身属性决定了其无法保留输入流中消息的边界信息。

数据传输的底层实现

在使用TCP套接字时，不能假设在连接的一端将数据写入输出流和在另一端从输入流读出数据之间有任何的一致性。尤其是在发送端由单个输出流的write()方法传输的数据，可能会通过另一端的多个输入流的read()方法获取，而一个read()方法可能会返回多个write()方法传输的数据。
一般来讲，可以认为TCP连接上发送的所有字节序列在某一瞬间被分成了3个FIFO队列：
1、SendQ：在发送端底层实现中缓存的字节，这些字节已经写入输出流，但还没在接收端成功接收。它占用大约37KB内存。
2、RecvQ：在接收端底层实现中缓存的字节，这些字节等待分配到接收程序——即从输入流中读取。它占用大约25KB内存。
3、Delivered：接收者从输入流已经读取到的字节。
当我们调用OutputStream的write()方法时，将向SendQ追加字节。
TCP协议负责将字节按顺序从SendQ移动到RecvQ。这里有重要的一点需要明确：这个转移过程无法由用户程序控制或直接观察到，并且在块中发生，这些块的大小在一定程度上独立于传递给write()方法的缓冲区大小。
接收程序从Socket的InputStream读取数据时，字节就从RecvQ移动到Delivered中，而转移的块的大小依赖于RecvQ中的数据量和传递给read()方法的缓冲区的大小。

示例分析

byte[] buffer0 = new byte[1000];
byte[] buffer1 = new byte[2000];
byte[] buffer2 = new byte[5000];
...
Socket socket = new Socket(addrest, port);
OutputStream outputStream = socket.getOutputStream();
...
outputStream.write(buffer0);
...
outputStream.write(buffer0);
...
outputStream.write(buffer0);
...
outputStream.close();
socket.close();

其中，圆点代表了其它代码，但不包含对out.write()方法的调用。这个TCP连接向接收端传输8000字节，在连接的接收端，这8000字节的分组方式取决于连接两端的out.write()方法和in.read()方法的调用时间差，以及提供给in.read()方法的缓冲区的大小。
下图展示了3次调用out.write（）方法后，另一端调用in.read()方法前，以上3个队列的一种可能的状态。
在某一时刻，SendQ队列中有6500字节，由TCP协议传输到RecvQ队列的字节数是1500，由于没有in.read()方法的调用，所以Delivered队列没有字节。假设此时接收者调用了read()方法时使用的缓冲区数组大小为2000字节，read()调用则将把RecvQ中的1500字节全部移动到数组中，返回值为1500。注意，这些数据中包含了第一次和第二次调用write()方法时传输的字节，再过一段时间，当TCP连接传完更多数据后，这三部分的状态可能如下图所示：

如果接收者现在调用read()方法时使用4000字节的缓冲区数组，将有很多字节从RecvQ队列转移到Delivered队列中，这包括第二次write()的2000个字节中剩下的1500字节加上第三次调用write()方法的2500字节。此时，队列的状态如下图：

下次再调用read()方法返回的字节数，取决于缓冲区数组的大小，以及发送方套接字通过网络向接收方实现传输数据的时机（数据从sendQ到RecvQ缓冲区的移动）。

死锁问题

SendQ和RecvQ缓冲队列，这两个缓冲区的容量在具体实现时会受一定的限制，虽然它们使用的实际内存大小会动态地增长和收缩，但还是需要一个硬性的限制，以防止行为异常的程序所控制的单一TCP连接将系统的内存全部消耗。正是由于缓冲区的容量有限，它们可能会被填满，事实也正是如此，如果与TCP的流量控制机制结合使用，则可能导致一种形式的死锁。
一旦RecvQ已满，TCP流控制机制就会产生作用（使用流控制机制的目的是为了保证发送者不会传输太多数据，从而超出了接收系统的处理能力），它将阻止传输发送端主机的SendQ中的任何数据，直到接收者调用输入流的read()方法将RecvQ中的数据移除一部分到Delivered中，从而腾出了空间。发送端可以持续地写出数据，直到SendQ队列被填满，如果SendQ队列已满时调用输出流的write()方法，则会阻塞等待，直到有一些字节被传输到RecvQ队列中，如果此时RecvQ队列也被填满了，所有的操作都将停止，直到接收端调用了输入流的read()方法将一些字节传输到了Delivered队列中。
假设SendQ队列和RecvQ队列的大小分别为SQS和RQS。将一个大小为n的字节数组传递给发送端write()方法调用，其中n > SQS，直到有至少n-SQS字节的数据传递到接收端主机的RecvQ队列后，该方法才返回。如果n的大小超过了SQS+RQS，write()方法将在接收端从输入流读取了至少n-(SQS+RQS)字节后才会返回。如果接收端没有调用read()方法，大数据量的发送是无法成功的。特别是连接的两端同时分别调用它的输出流的write()方法，而他们的缓冲区大小又大于SQS+RQS时，将会发生死锁：两个write操作都不能完成，两个程序都将永远保持阻塞状态。因此，在写程序时，要仔细设计协议，以避免在两个方向上传输大量数据时产生死锁。

建立TCP连接

客户端连接的建立

当客户端以服务器端的互联网地址和端口号作为参数，调用Socket的构造函数时，底层实现将创建一个套接字实例，该实例的初始状态是关闭的。TCP开放握手也称为3次握手，这通常包括3条消息：一条从客户端到服务端的连接请求，一条从服务端到客户端的确认消息，以及另一条从客户端到服务端的确认消息。对客户端而言，一旦它收到了服务端发来的确认消息，就立即认为连接已经建立。通常这个过程发生的很快，但连接请求消息或服务端的回复消息都有可能在传输过程中丢失，因此TCP协议实现将以递增的时间间隔重复发送几次握手消息。如果TCP客户端在一段时间后还没有收到服务端的回复消息，则发生超时并放弃连接。如果服务端并没有接收连接，则服务端的TCP将发送一条拒绝消息而不是确认消息。

服务端连接的建立

与客户端的事件序列则有所不同,服务端首先创建一个ServerSocket实例，并将其与已知端口相关联，套接字实现为新的ServerSocket实例创建一个底层数据结构。
现在服务端可以调用ServerSocket的accept()方法，来将阻塞等待客户端连接请求的到来。当客户端的连接请求到来时，将为连接创建一个新的套接字数据结构。该套接字的地址根据到来的分组报文设置：分组报文的目标互联网地址和端口号成为该套接字的本地互联网地址和端口号；而分组报文的源地址和端口号则成为改套接字的远程互联网地址和端口号。注意，新套接字的本地端口号总是与ServerSocket的端口号一致。除了要创建一个新的底层套接字数据结构外，服务端的TCP实现还要向客户端发送一个TCP握手确认消息。
但是，对于服务端来说，在接收到客户端发来的第3条消息之前，服务端TCP并不会认为握手消息已经完成。一旦收到客户端发来的第3条消息，则表示连接已建立，此时一个新的数据结构将从服务端所关联的列表中移除，并为创建一个Socket实例，作为accept()方法的返回值。

关闭TCP连接

TCP协议有关闭机制，以保证应用程序在关闭时不必担心正在传输的数据会丢失，这个机制还可以设计为允许两个方向的数据传输相互独立地终止。关闭机制的工作流程是：应用程序通过调用连接套接字的close()方法或shutdownOutput()方法表明数据已经发送完毕。底层TCP实现首先将留在SendQ队列中的数据传输出去（这还要依赖于另一端的RecvQ队列的剩余空间），然后向另一端发送一个关闭TCP连接的握手消息。该关闭握手消息可以看做流结束的标志：它告诉接收端TCP不会再有新的数据传入RecvQ队列了。注意：关闭握手消息本身并没有传递给接收端应用程序，而是通过read()方法返回-1来指示其在字节流中的位置。而正在关闭的TCP将等待其关闭握手消息的确认消息，该确认消息表明在连接上传输的所有数据已经安全地传输到了RecvQ中。只要收到了确认消息，该连接变成了“半关闭”状态。直到连接的另一个方向上收到了对称的握手消息后，连接才完全关闭——也就是说，连接的两端都表明它们没有数据发送了。
TCP连接的关闭事件序列可能以两种方式发生：一种方式是先由一个应用程序调用close()方法或shutdownOutput()方法，并在另一端调用close()方法之前完成其关闭握手消息；另一种方式是两端同时调用close()方法，他们的关闭握手消息在网络上交叉传输。