TCP三次握手，四次分手
TCP UDP
TCP：1.面向链接（如打电话须要先拨号创建链接）；
2.提供可靠的服务，经过TCP传送的数据，无差错，不丢失，不重复，且按序到达；
3.面向字节流，其实是TCP把数据当作一连串无结构的字节流；
4.有拥塞控制
5.每一条TCP链接只能是点到点的
6.TCP首部开销20字节
7.TCP是全双工的可靠信道
UDP：1.无链接，发送数据以前不须要创建链接 ；
2. 尽最大努力交付，不保证可靠交付
3. UDP是面向报文的，应用层交给UDP多长的报文，UDP就照样发送，即一次只发送一个报文，
4. UDP没有拥塞控制，所以网络出现拥塞不会使源主机发送速率下降（对实时应用颇有用，好比IP电话，视频会议等，容许丢一点数据）
5. UDP支持一对一，一对多，多对一和多对多的交互通讯
6. UDP首部开销小，只有3字节
7. UDP是不可靠信道
TCP和UDP用于一个端口发送信息是否冲突？
不冲突，TCP/UDP能够绑定同一端口来进行通讯，不少协议已经这样作了，例如DNS适用于udp/53和tcp/53。由于数据接收时根据五元组（传输协议，源IP，目的IP，源端口，目的端口）来判断接收者的。
再举一个例子，好比一个服务器监听80端口，他为何能够创建成千上万个链接？
一个TCP链接须要由四元组来造成，即(src_ip,src_port,dst_ip,dst_port)。当一个链接请求过来的时候，服务端调用accept函数，新生成一个socket，这个socket所占用的本地端口依然是80端口。由四元组就很容易分析到了，同一个(src_ip,src_port)，它所对应的(dst_ip,dst_port)能够无穷变化，这样就能够创建不少个客户端的请求了。web
TCP 三次握手
Round 1 客户端发送链接请求报文段，不传输数据。
SYN = 1, seq = x （随机）
Round 2 服务器为该TCP链接分配缓存和变量，并向客户端返回确认报文段，容许链接，不传输数据。
ACK = 1, SYN = 1, seq = y（随机），ack = x+1;
Round 3 客户端为TCP链接分配缓存和变量，并向服务器端返回确认的确认，能够携带数据。
SYN = 0, ACK = 1, seq = x+1， ack = y+1；算法
ACK =1时，确认号有效（这句话的意思是ACK =1, ack就是有效的），在链接创建后，全部传送的报文段都必须把ACK置为1。
SYN=1时，代表是一个链接请求/链接请求接受报文。缓存
为何是三次握手，而不是两次
在服务器端对客户端的请求进行回应（第二次握手后)，就会理所应当的认为链接已经创建，但若是客户端没有服务器的回应呢，此时客户端仍认为链接未创建，服务器端会对已经创建的链接保存必要的资源，若是出现大量这种状况，服务器会崩溃。服务器
SYN攻击
SYN泛洪攻击，攻击者经过发送TCP SYN，也就是三次握手中的第一个数据包，当服务返回ACK后，该攻击者就不对其进行再确认，那么这个TCP链接就会处于办链接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者，这样就会更加浪费服务器的资源。攻击者回发送很是大量的这种TCP链接，因为每个都没法完成三次握手，因此在服务器上，这些TCP链接会由于挂起状态而消耗CPU和内存，醉胡服务器可能会死机，就没法为正经常使用户提供服务了。网络
四次分手
Round 1 客户端发送链接释放报文段，中止发送数据，主动关闭TCP链接。
FIN = 1, seq = u；
Round 2 服务器端返回一个确认报文段，客户端到服务器这个方向的链接就释放了—半关闭状态。
ACK = 1, seq = v, ack = u+1;—服务器端仍有数据传输
Round 3 服务器端发完数据，就发出链接释放报文段，主动关闭TCP链接
FIN = 1, ACK = 1, seq = w, ack = u+1； —无数据传输
Round 4 客户端回送一个确认报文段，再等到时间等待计时器设置的2MSL（最长报文段寿命）后，链接完全关闭。
ACK = 1, seq = u+1, ack = w+1;socket
为何是四次分手，而不是三次
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后。它可以把ACK和SYN（ACK起应答做用。而SYN起同步做用）放在一个报文里来发送。但关闭链接时，当收到对方的FIN报文通知时，它只表示对方没有数据发送给你了。但未必你全部的数据都全部发送给对方了。因此你可以未必会当即会关闭SOCKET,也即你可能还需要发送一些数据给对方以后，再发送FIN报文给对方来表示你容许现在可以关闭链接了。因此它这里的ACK报文和FIN报文多数状况下都是分开发送的。tcp
为何要等待2MSL
很简单，由于最后一次关闭的ACK你永远没法知道对方是否有收到，因此须要等待一个包在网络中存在的最大周期，若是超过这个周期ACK没有发送到对方位置，发送端就会收到丢包命令（这个命令是由网络控制协议发出的），进而能够进行重发，反之则认为对方收到了ACK，结束wait。svg
TCP保证可靠传输的机制
（1）数据排序
TCP有专门的序号字段，提供数据re-order；
一个字节占一个序号，TCP是按照包来发送的，一个包里面能够装两个字节/三个字节/。。。
序号字段指的是一个报文段第一个字节的序号。函数
（2） 确认和重传机制
创建链接时，三次握手同步双方的“序列号+窗口大小信息”，是确认重传，流量控制的基础。
接收方会对收到的数据包进行一个累计确认，在合适的时候发送一个确认报文段，告诉发送方我已经收到了这个信息。
同时接收方有时候也能够在本身有数据须要发送的时候，将这个确认信息捎带着一块儿发送，就是咱们常说的捎带确认。
发送发根据序号判断本身有无按序到达，若是有丢包现象的话，会进行重传。大数据
确认机制和重传机制是密切相关的。TCP的发送方在规定时间内没有收到确认就要重传已发送的报文段，超时重传。
TCP采用自适应算法，动态改变重传时间RTTs（加权平均往返时间）
传输过程当中，若是checksum校验失败，丢包或者延时，发送端重传。
冗余ACK：
每当比指望序号大的失序报文段到达时，都发送一个冗余ACK，指明下一个期待字节的序号。
发送方已发送1，2，3，4，5报文段
接收方收到1，返回给1的确认（确认号为2的一个字节）
接收方收到3，仍返回给1的确认（确认号为2的一个字节）
接收方收到4，仍返回给1的确认（确认号为2的一个字节）
接收方收到5，仍返回给1的确认（确认号为2的一个字节）
发送方收到3个对于报文段1的冗余ACK，认为2报文段丢失，重传2号报文段 快速重传。
（3）流量控制（让发送方发送慢点，要让接收方来得及接收）
在通讯过程当中，接收方根据本身接收缓存的大小，动态的调整发送方发送端口的大小，即接收窗口rwnd（接收方设置确认报文段的窗口字段来将rwnd通知给发送方），发送方的发送窗口取接收窗口rnwd和拥塞窗口cwnd的最小值。
滑动窗口和计时器的使用，TCP窗口中会指明双方可以发送接收的最大数据量，发送方经过维持一个发送滑动窗口来确保不会发生因为发送方报文发送太快接收方没法及时处理的问题。
（4）拥塞控制
TCP的拥塞控制由4个核心算法组成：
“慢开始”（Slow Start）
“拥塞避免”（Congestion avoidance）
“快重传 ”（Fast Retransmit）
“快恢复”（Fast Recovery）