这是在学习中的总结，若有错误请大家不吝指正（^.^）

关于TCP/IP的三次握手：

当服务端的状态为LISTEN，客户端的状态为CLOSED时，客户端发起连接

客户端发送有SYN字段报文，此时状态为SYN_SENT状态

服务端接收该报文时，状态处于SYN_REVD状态，并向客户端发送有SYN与ACK字段的报文

客户端接收到该报文时，状态处于ESTABLISHED（建立）状态，并发送有ACK字段的报文

服务端接收到报文后，状态处于ESTALISHED（建立）状态，并开始数据的交互

 

关于糊涂窗口：

当在网络数据传输中，大量发送含有少量数据的报文（极端情况一个报文只有一字节数据），因为在协议层中对数据是层层封装的过程，因此对于数据来说有大量的协议头，传输开销过大；或接收端在缓存区接受数据过慢；

解决方法：

发送端使用Nagle算法，当发送包长度小于MSS大小时会等待一会，发送条件是：

直到所有发送的小包都有ACK回复且未设置TCP_CORK时；

直到有FIN字段时；

直到数据长度达到MSS时；

直到等待超时（一般200ms）；

设置TCP_NODELAY且没有设置TCP_CORK时；（就是不使用优化算法啦）

（当小包的ACK字段接收较快时算法的作用不大）

发送端使用CORK算法，会将小包拼接成大包，是协议头在协议报文的比重减小，发送条件是：

拼接的报文大于MTU或超时；

没有设置TCP_CORK并设置TCP_NODELAY时；（就是不使用优化算法啦）

（当小包的传输时间间隔不短时影响实时性，因为都要等待超时传输）

接收端使用Clark解决，只要有数据到达就确认，但宣布窗口大小为0，直到缓存空间够容纳一个MSS或缓存空间一半已空；

接收端延迟确认，直到缓存空间足够为止，防止TCP发送端窗口的滑动，可以减少通信量，不必确认每个报文段，但延迟的确认会导致重发。

 

关于粘包问题：

因为要解决糊涂窗口而使数据积攒发送，或收端不及时接受缓存区数据而同时接收多个包，会导致发送的原数据接收后拼接在一起无法分离。

解决方法：

当数据传输是一次交互后立即断开（多个Client与一个Server）时，数据无结构时（文件传输，一方发另一方收），使用UDP时（有消息边界）不会产生粘包问题；

发送端设置强制数据立即发送，不必等待缓存区满（无处理优化，效率降低）；

接收端优化编程方法，精简接收过程，提高接收优先级等使其接收效率提高（不能完全避免）；

接收端按结构字段、人为控制多次接收，然后合并（效率低，对实时场合不适用）；


在这里问一下，怎么美化呀j_0074.gif，之前看别人的博客很酷炫的j_0079.gif