TCP
三次握手
第一次：客户端发送SYN，进入SYN_SEND状态。
第二次：服务端收到SYN，并发送SYN和ACK，由LISTEN状态变为SYN_RECVD状态。
第三次：客户端收到SYN和ACK，发送ACK报文，进入到ESTABLISHED状态。（服务端收到后也进入ESTABLISHED状态）
四次挥手（客户端和服务端均可主动关闭）
第一次：客户端传送给服务端的数据传输完成后，发送FIN，进入FIN_WAIT1状态。
第二次：服务端收到FIN，若有数据还需传送给客户端，则继续传输数据，传输完成后发送ACK。
第三次：客户端收到ACK，进入FIN_WAIT2状态。服务端传输FIN，进入LAST_ACK状态。
第四次：客户端收到FIN，发送ACK。服务端收到ACK，直接进入CLOSED状态。等待2MSL(最大报文生存时间)后进入CLOSED状态。
p.s.
SYN 同步序列号，TCP建立连接时会将该位置1。
ACK 由目的端发出，表示确认号之前的数据段都收到了。e.g.确认号为X，则表示前X-1个数据段都收到了，只有ACK =1是确认号才有效。若ACK =0,为保证数据的完整性，发送端需重传数据。
FIN 当需要断开数据传输时，提出断开的一方将该位置1。
RST 表示重置，重新建立连接。
MSL最大报文生存时间，一般是30s,1min或2min。
TTL（time-to-live生存时间)，并不是具体的时间，而是设置了数据报可以经过的最大路由器的数目，每经过一个路由器，该值减一。当TTL为0,该数据报被丢弃。
RTT往返时间，TCP的超时与重传需要对一个给定连接的往返时间RTT的测量。由于路由器和网络流量均会变化，因此RTT也经常变化。
QA：
1.为什么收到服务端的确认后，客户端还需第三次握手？
为了防止失效的请求报文段突然又传到服务端，因而产生错误。
e.g.客户端发送到服务端的SYN报文在网络中长时间滞留，直到连接释放后才到达服务端，若没有第三次握手，则服务端就会建立连接，并一直监听客户端，造成服务端资源的浪费。
2.为什么要四次挥手？
保证数据能够完成传输。
一方发送FIN，只表示该方没有数据发送给另一方了，但另一方可能仍有数据发送给该方。要等到两方都没有数据发送给对方，才可以断开连接。
3.第二次握手时的SYN有什么用？
丢弃重复的失效的报文。
客户端发送SYN给服务端，若长时间没有收到服务端的回复，会超时重传SYN。此时网络中就会有两个SYN，后到服务器的SYN是无效的，服务器为了判断收到的SYN的有效性，会发送SYN给客户端查询该SYN报文的有效性。
客户端发起握手请求，服务端无法立即建立连接会回复什么？
RST报文
4.TIME_WAIT产生的原因？
1）可靠地实现TCP连接的关闭
我们不能保证服务端一定能够收到最后的ACK报文。若客户端发送ACK后直接进入CLOSED状态，当ACK报文丢失时，服务端长时间没有收到客户端回复，会重传FIN报文，此时会收到一个RST，服务端会认为有错误发生，不能正常的关闭连接，造成服务端资源的浪费。而让客户端处于TIME_WAIT就不会出现这种情况，在再次收到服务端的FIN后，客户端会重传ACK，并重新计时。
2）保证本连接内的重复报文在网络中消逝，避免影响下一次的连接。
TCP v.s UDP
1）连接
2）可靠性：TCP提供交付保证，若信息在传输时丢失，将会重发。UDP不提供任何交付保证。
3）有序性：消息到达另一端可能是无序的，TCP为排好序，UDP不会。
4）速度：TCP慢，适合传输大量数据；UDP快，适合传输少量数据。
5）量级：TCP重量级协议，报头包含序列号，ACK号，数据偏移量、保留、控制位、窗口、紧急指针、可选项、填充项、校验位、源端口和目的端口，至少20字节。UDP轻量级，报头只包含长度、源端口号、目的端口、校验和，固定8字节。
6）流量控制和拥塞控制：TCP有，UDP无。
7）TCP面向字节流，UDP面向报文。
8）TCP只能单播，不能发送广播和组播；UDP皆可。
TCP 应用场景： 效率要求相对低， 但对准确性要求相对高的场景。 因为传输中需要 对数据确认、 重发、 排序等操作， 相比之下效率没有 UDP 高。 举几个例子： 文件传输、 邮 件传输、 远程登录。
UDP 应用场景： 效率要求相对高， 对准确性要求相对低的场景。 举几个例子： QQ 聊天、 QQ 视频、 网络语音电话（即时通讯， 速度要求高， 但是出现偶尔断续不是太大问 题， 并且此处完全不可以使用重发机制） 、 广播通信（广播、 多播） 。