TCP和UDP协议
UDP：不可靠，无连接，时延小，适用于小文件
TCP：面向连接，时延大，适用于大文件；确保可靠性：三次握手，超时重传，滑动窗口，拥塞控制。
- TCP协议中包含了专门的传递保证机制，当数据接收方收到发送方传来的信息时，会自动向发送方发出确认消息；发送方只有在接收到该确认消息之后才继续传送其它信息，否则将一直等待直到收到确认信息为止。 与TCP不同，UDP协议并不提供数据传送的保证机制。如果在从发送方到接收方的传递过程中出现数据报的丢失，协议本身并不能做出任何检测或提示。
- UDP具有TCP所望尘莫及的速度优势。虽然TCP协议中植入了各种安全保障功能，但是在实际执行的过程中会占用大量的系统开销，无疑使速度受到严重的影响。反观UDP由于排除了信息可靠传递机制，将安全和排序等功能移交给上层应用来完成，极大降低了执行时间，使速度得到了保证。
TCP三次握手
过程
- 主机 A 向主机 B 发送 TCP 连接请求数据包，其中包含主机 A 的初始序列号 seq(A)=x。（其中报文中同步标志位 SYN=1，ACK=0，表示这是一个 TCP 连接请求数据报文；序号 seq=x，表明传输数据时的第一个数据字节的序号是 x）；
- 主机 B 收到请求后，会发回连接确认数据包。（其中确认报文段中，标识位 SYN=1，ACK=1，表示这是一个 TCP 连接响应数据报文，并含主机 B 的初始序列号 seq(B)=y，以及主机 B 对主机 A初始序列号的确认号 ack(B)=seq(A)+1=x+1）
- 第三次，主机 A 收到主机 B 的确认报文后，还需作出确认，即发送一个序列号 seq(A)=x+1；确认号为 ack(A)=y+1 的报文；
三次握手为什么不用两次?
- 主要是为了防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送的第一个请求连接并且没有丢失，只是因为在网络中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时之前滞留的那一次请求连接，因为网络通畅了, 到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的费。
- 如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
为什么不用四次?
- 因为三次已经可以满足需要了, 四次就多余了.
TCP四次挥手
过程
- 关闭客户端到服务器的连接：首先客户端 A 发送一个 FIN，用来关闭客户到服务器的数据传送，然后等待服务器的确认。其中终止标志位 FIN=1，序列号 seq=u。
- 服务器收到这个 FIN，它发回一个 ACK，确认号 ack 为收到的序号加 1。
- 关闭服务器到客户端的连接：也是发送一个 FIN 给客户端。
- 客户段收到 FIN 后，并发回一个 ACK 报文确认，并将确认序号 seq 设置为收到序号加1。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
为什么最后客户端还要等待 2*MSL的时间呢?
MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。
-
第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
-
第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
为什么建立连接是三次握手，关闭连接确是四次挥手呢？
- 建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
- 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。
如果已经建立了连接, 但是客户端突发故障了怎么办?
- TCP设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
TCP超时重传
TCP滑动窗口
TCP拥塞控制
四种算法
- 慢开始
- 拥塞避免
- 快重传
- 快恢复
慢开始和拥塞避免
这里开始时以指数形式增长，ssthresh的意思是慢开始门限，代表从这个地方注入的报文段就比较多了，需要开始慢速增加了。
之后一段都是线性增长，每次增加1，直至达到网络拥塞状态
瞬间将cwnd设置为1，同时调整原来的ssthresh的值到之前达到网络拥塞状态的1/2,（这里是24降到12）
重复以上步骤，但是注意此时ssthresh变了之后线性增长的转折点也变了
快重传和快恢复
这里和上面的慢开始和拥塞避免的一开始步骤差不多，都是先指数增长再转变为线性增长。
不同的点是快重传和快恢复算法是在收到连续的ack确认之后执行，这里的ack就是冗余ack，冗余ack的特点是如果多次对某一段请求的数据没有被收到，达到一定数目之后就会立即执行重传。但是此时只是降到现在cwnd的一半，再重新线性增长。而不是像慢开始和拥塞避免的从头开始
