1.拥塞控制原理
正常的情况，我们网络中的流量是成正比的，当出现拥堵时，随着流量增加，会出现吞吐量下降的情况，此时就产生了拥堵，严重的情况下，路由器可能出现死机。
1.1拥塞的解决办法
1.1.1慢开始和拥塞避免
在TCP建立连接时，接收方会告诉发送方自己的最大报文段MMS、接受窗口的大小rwnd,但是发送方并不会设置成接收方最大窗口，而是设置拥塞窗口，也就是发送窗口cwnd。按此发送方会先发一个来感知当前网络状态，如果未出现丢包成倍增加，理想状态下逐步达到接受窗口。看下图
1.1.2 快重传和快恢复
快重传：1.发送方传数据是依次发送，当发现一个数据包丢失之后，先发送后面的数据包，等待丢失的数据包超时之后，再次发送丢失的数据包。
2.接收方如果发现有一个数据包丢失之后，他也会发送三个确认，告诉发送方该发丢失的数据包了。
快恢复：对比前一个拥塞方法，当拥塞发生将从新的ssthresh(拥堵时的值除以二）
2.三次握手
第一次：客户端的状态是close,客户端发送连接报文，ACK(确认号为0)此时没有收到信息，序列号seq(随机生成）syn同步数据为1 ，发送完之后处于SYN-SENT状态。
第二次：服务器收到客户端的发送数据后应答为ACK=1，代表收到了客户端的数据，ack加一，生成一个随机序列号。此时处于监听状态。
第三次：客户端应答。
为什么需要三次握手：当客户端发送建立连接的请求时，可能讲过的路由器比较多，在客户端等待服务器响应的时候，出现了超时，此时的客户端发现服务器没有响应，它又发送了一个请求，这次的请求经过的路由器比较少，并且得到了服务器的响应。此时客户端第一次发送的请求连接到达服务器，服务器返回响应，但是客户端已经把第一次发送的连接请求作废，这就导致服务器发送确认但是客户端理解成为无效的确认，这就导致服务器一直在等待客户端来建立连接，浪费服务器资源。这就需要第三次握手，当收到客户端的应答之后，服务器就不会存在一直等待连接的问题
3.四次挥手
第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。
即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。
注意：在关闭连接的时候客户端有一个等待的过程，这个原因是在最后一次挥手，万一出现了客户端发的消息 服务器没有收到，那么低三次挥手要重新发送，所以等待一段时间是为了确定挥手成功。