关于TCP连接方面的一些问题

TCP连接只能由客户端主动关闭连接吗?

不是，服务端可以主动关闭连接的。

滑动窗口和拥塞控制中的拥塞窗口是一个概念吗?

滑动窗口和拥塞窗口是在解决两个正交的问题，只不过方法上都是在调整主机发送数据包的速率。滑动窗口是解决Flow Control的问题，就是如果接收端和发送端对数据包的处理速度不同，如何让双方达成一致。而拥塞窗口是解决多主机之间共享网络时出现的拥塞问题的一个修正。客观来说网络信道带宽不可能允许所有主机同时全速通信，所以如果全部主机都全速发送数据包，导致网络流量超过可用带宽，那么由于TCP的设计数据包会大量丢失，于是由于重传机制的触发会进一步加剧拥塞，潜在的导致网络不可用。

TCP是怎么保证数据包的有序传递的?

数据包是不一定先发先到，但是对于TCP有一点特殊，若我们接受的数据包是在应用层，并且应用层用的是TCP的传输协议的话，这个顺序是保证，这个顺序的保证是在传输层保证的，举个例子：

client发生数据A,B给server，使用的TCP传输，client发送毫无疑问是先发送A，然后发送B，但是有些搞网络的同学可能会有这个疑问，A跟B在物理层走的链路不一样，传输速度不一样，B是会比A先到达Server,这个是没有错的，但是这个数据包被接受是在网络层跟传输层，请记住网络跟传输层的作用，网络层是保证同一个包的完整，就是说若你的传输层发出的包过大，在网络层（也就是IP层）会被分包，同时在Sever的网络接受的时候会被组包，有一个完整的包才会交给传输层，若包不完整是会丢弃，同时他也不保证你的包的是否达到，数据包的保证是在传输层做的，就是说若传输层(TCP协议才会，UDP并不保证)没有收到对方的确认包，会有超时重传，每个数据包也是有序列号的，同时，传输层就是根据这个序列号来保证A,B包的顺序，即使B比A先到达了，TCP也会是等A到达之后，先把A提交给应用层，再把B的数据提交给应用层，从而保证了，同一条TCP链接，先发的包先到

注：这个顺序的保证是传输层做的，TCP这个协议保证的，UDP并不保证，网络层接收包的顺序是错乱的。

有序发包.png

发送不定长数据的时候，包尾的作用是什么

包尾：和包头一起过滤非法包，那么什么是非法包呢？例如接收到的包头中标明数据体的长度是m，但是实际发送的数据包大小为M(M>m),如果没有包尾存在就会认为接收了m长度数据是正确的，但是实际整个包都是错误的，应该丢弃。所以需要加入包尾保证包体大小

保护消息边界和流

那么什么是保护消息边界和流呢?

保护消息边界，就是指传输协议把数据当作一条独立的消息在网上传输，接收端只能接收独立的消息。也就是说存在保护消息边界，接收端一次只能接收发送端发出的一个数据包。而面向流则是指无保护消息保护边界的，如果发送端连续发送数据，接收端有可能在一次接收动作中，会接收两个或者更多的数据包。

例如，我们连续发送三个数据包，大小分别是2k，4k ，8k,这三个数据包，都已经到达了接收端的网络堆栈中，如果使用UDP协议，不管我们使用多大的接收缓冲区去接收数据，我们必须有三次接收动作，才能够把所有的数据包接收完.而使用TCP协议，我们只要把接收的缓冲区大小设置在14k以上，我们就能够一次把所有的数据包接收下来，只需要有一次接收动作。

注意：

这就是因为UDP协议的保护消息边界使得每一个消息都是独立的。而流传输却把数据当作一串数据流，他不认为数据是一个一个的消息。所以有很多人在使用tcp协议通讯的时候，并不清楚tcp是基于流的传输，当连续发送数据的时候，他们时常会认识tcp会丢包。其实不然，因为当他们使用的缓冲区足够大时，他们有可能会一次接收到两个甚至更多的数据包，而很多人往往会忽视这一点，只解析检查了第一个数据包，而已经接收的其他数据包却被忽略了。所以大家如果要作这类的网络编程的时候,必须要注意这一点。

结论：

（1）TCP为了保证可靠传输，尽量减少额外开销（每次发包都要验证），因此采用了流式传输，面向流的传输，相对于面向消息的传输，可以减少发送包的数量，从而减少了额外开销。但是，对于数据传输频繁的程序来讲，使用TCP可能会容易粘包。当然，对接收端的程序来讲，如果机器负荷很重，也会在接收缓冲里粘包。这样，就需要接收端额外拆包，增加了工作量。因此，这个特别适合的是数据要求可靠传输，但是不需要太频繁传输的场合（两次操作间隔100ms，具体是由TCP等待发送间隔决定的，取决于内核中的socket的写法）

（2）UDP，由于面向的是消息传输，它把所有接收到的消息都挂接到缓冲区的接受队列中，因此，它对于数据的提取分离就更加方便，但是，它没有粘包机制，因此，当发送数据量较小的时候，就会发生数据包有效载荷较小的情况，也会增加多次发送的系统发送开销（系统调用，写硬件等）和接收开销。因此，应该最好设置一个比较合适的数据包的包长，来进行UDP数据的发送。（UDP最大载荷为1472，因此最好能每次传输接近这个数的数据量，这特别适合于视频，音频等大块数据的发送，同时，通过减少握手来保证流媒体的实时性）