前置：争取在三天内用hexo搭个博客

TCP和UDP相关

TCP和UDP的区别有哪些？

• 基于连接与无连接
• TCP可靠传输，UDP不可靠（尽最大努力进行报文的交付）
• TCP要求系统资源较多，UDP较少
• UDP程序结构较简单
• 流模式（TCP）与数据报模式(UDP)
• TCP保证数据顺序，UDP不保证

TCP如何保证传输的可靠性？

• 数据包校验
• 对失序数据包重新排序（TCP报文具有***）
• 丢弃重复数据
• ACK应答+超时重传：接收方收到数据之后，会发送一个确认。而发送方发出数据之后，启动一个定时器，超时未收到接收方的确认，则重新发送这个数据；
• 流量控制：确保接收端能够接收发送方的数据而不会缓冲区溢出

什么时候选择TCP，什么时候选UDP？

• 对某些实时性要求比较高的情况，选择UDP，比如游戏、媒体通信、直播，即使出现传输错误也可以容忍。
• 其它大部分情况下，HTTP都是用TCP，因为要求传输的内容可靠，不出现丢失。

什么是三次握手？

什么是四次挥手？

为什么要三次挥手？两次不行吗？

• 可能会出现已失效的连接请求报文段又传到了服务器端。 client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用 “三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据，这样server 会白白浪费很多资源。三次握手可以防止上述现象发生。
• 其次，两次握手无法保证Client正确接收第二次握手的报文（Server无法确认Client是否收到），无法保证Client和Server之间成功互换初始***。

为什么要四次挥手？三次不行吗？

• 因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可能未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

TCP拥塞控制

• 慢开始：【发送窗口】cwnd=cwnd*2指数增加到【拥塞窗口】ssthresh
• 拥塞控制：线性增加。如发生超时重传，ssthresh=cwnd/2，cwnd=1
• 快重传&快恢复：连续收到3个重复确认，cwnd=ssthresh=cwnd/2，直接进入拥塞避免，线性增加

【深度好文】
【TCP拥塞控制】