标签：ack 应用程序 user 数据流 常用 服务器端 同步 重复 net
1-传输层网络层只把分组发送到目的主机，但是真正通信的并不是主机而是主机中的进程。传输层提供了进程间的逻辑通信， 传输层向高层用户屏蔽了下面网络层的核心细节，使应用程序看起来像是在两个传输层实体之间有一条端到端的逻辑 通信信道。
用户数据报协议 UDP（User Datagram Protocol）是无连接的，尽大可能交付，没有拥塞控制，面向报文 （对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多 的交互通信。
0-1023：知名端口号，HTTP\FTP\SSH等应用层端口都是固定的
1024-65535：客户端程序端口号，操作系统动态分配的端口号
知名端口号：
ssh服务器--22
ftp服务器--21
teInet服务器--23
http服务器---80
https服务器--443
一开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。
然后客户端主动发起连接 SYN，之后处于 SYN-SENT 状态。
服务端收到发起的连接，返回 SYN，并且 ACK 客户端的 SYN，之后处于 SYN-RCVD 状态。
客户端收到服务端发送的 SYN 和 ACK 之后，发送 SYN 的 ACK，之后处于 ESTABLISHED 状态，因为它一发一收成功了。
·1第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。
客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待 一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求后还是会到达服务器，如果不进行三次握 手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确 认，不进行第三次握手，因此就不会再次打开连接。
2.保证双方的序号是同步的，这是TCP可靠传输的重要原因
每一个SYN都要有对应的ACK，确保双方都具有发送和接收数据的功能
3.防止资源浪费
客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。
服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。
客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。
等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。
客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
服务器收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。
客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服 务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。
客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器 设置的时间 2MSL。这么做有两个理由：2MSL怎么来的
(1)确保后一个确认报文ACK能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文， A 等待一段时间就是为了处理这种情况的发生。
(2)等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧 的连接请求报文。
MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为 TCP 报文基于是 IP 协议的
而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报文通知源主机。MSL 与 TTL 的区别：MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是：
网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。
是什么？为什么？怎么做
超时重传、滑动窗口、流量控制、拥塞控制
（1）确认和重传机制：建立连接、发送包时的确认，运输过程中校验失败、丢包或延时发送端重传
（2）数据排序：把数据分成很多包，按顺序进行传输
（3） 流量控制：滑动窗口和计时器
（4）拥塞控制：慢启动、拥塞避免、快速重传、快速恢复
如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文 段。
流量控制是为了控制发送方发送速率，保证接收方来得及接收，作用于接收方，防止分组丢失的。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
作用于网络，防止过多的数据注入到网络中，避免出现网络负载过大的情况。
拥塞窗口：
发送数据端使用的窗口大小，拥塞窗口不代表缓存，拥塞窗口指某一源端数据流在一个RTT内可以最多发送的数据包数。
当主机开始发送数据时，如果立即将大量数据字节注入到网络，那么就有可能因为不清楚当前网络的负荷情况而引起网络阻塞。所以，最好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚发送报文段时，先把拥塞窗口cwnd设置为 1 个最大报文段MSS的数值。而在每收到一个新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值（1个确认报文对应2个MSS，即：呈指数增长）。用这样的方法逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。
注意：慢开始当中的“慢”并不是指cwnd的增长速率慢，而是在TCP开始发送报文段时先设置cwnd = 1,使得发送方在开始时只发送一个报文段。
让拥塞窗口cwnd缓慢的增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd + 1，而不是加倍，即：呈线性增长。这样拥塞窗口cwnd按线性规律缓慢的增长，比慢开始算法的拥塞窗口增长速率缓慢的多。
所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。
发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法；发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半；开始执行拥塞避免算法。
(阈值ssthresh的作用是：当下一次出现超时，慢启动到阈值后开始启动拥塞避免。)
给每个字节都进行编号，即序列号 。每个ACK都有对应的确认序列号，告诉发送者，已经收到哪些数据，下一次从哪里开始
因为有序列号还可以进行因重传机制可能导致的重复包的问题
一般每隔2个包，应答一次，延迟应答时间不超过超时时间，一般是200ms
1. 连接
TCP 是面向连接的传输层协议，传输数据前先要建立连接。
UDP 是不需要连接，即刻传输数据。
2. 服务对象
TCP 是一对一的两点服务，即一条连接只有两个端点。
UDP 支持一对一、一对多、多对多的交互通信
3. 可靠性
TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达。
UDP 是尽最大努力交付，不保证可靠交付数据。
4. 拥塞控制、流量控制
TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。
UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。
5. 首部开销
TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是 20 个字节，如果使用了「选项」字段则会变长的。
UDP 首部只有 8 个字节，并且是固定不变的，开销较小。
HTTP、HTTPS、FTP、SMTP、自己写TCP程序时自定义应用层协议
DNS、DHCP动态主机配置协议
解答：如果物理层，数据链路层或网络层能提供可靠性的话，那么UDP就可以利用下面各层的可靠性实现自己的可靠性；然鹅，UDP是不可靠的，也就是说他之下的各层并不能保证可靠性，所以只能靠上面的应用层（加上ACK等重传机制）来保证可靠性 
参考：
1.版权声明：本文为CSDN博主「飞行的小猪」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/yy2017220302028/article/details/104631286
2.公众号 小林coding
标签：ack 应用程序 user 数据流 常用 服务器端 同步 重复 net
原文地址：https://blog.51cto.com/14234228/2507068
