这是在学习中的总结，若有错误请大家不吝指正（^.^）
关于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时（有消息边界）不会产生粘包问题；
发送端设置强制数据立即发送，不必等待缓存区满（无处理优化，效率降低）；
接收端优化编程方法，精简接收过程，提高接收优先级等使其接收效率提高（不能完全避免）；
接收端按结构字段、人为控制多次接收，然后合并（效率低，对实时场合不适用）；
在这里问一下，怎么美化呀
，之前看别人的博客很酷炫的
另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。