WEB服务器与客户机的对话过程

简单的说这个过程叫做三次握手协议
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念：
未连接队列：在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。
Backlog参数：表示未连接队列的最大容纳数目。
SYN-ACK 重传次数 服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。
半连接存活时间：是指半连接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。

udp 和tcp 是 OSI 模型中的运输层中的协议。tcp 提供可靠的通信传输，而 udp 则常被用于让广播和细节控制交给应用的通信传输。两者的区别大致如下：
tcp 面向连接，udp 面向非连接即发送数据前不需要建立连接；
tcp 提供可靠的服务（数据传输），udp 无法保证；
tcp 面向字节流，udp 面向报文；
tcp 数据传输慢，udp 数据传输快；
tcp 为什么要三次握手，两次不行吗？为什么？ 我们假设A和B是通信的双方。我理解的握手实际上就是通信，发一次信息就是进行一次握手。
第一次握手：A给B打电话说，你可以听到我说话吗？
第二次握手：B收到了A的信息，然后对A说：我可以听得到你说话啊，你能听得到我说话吗？
第三次握手：A收到了B的信息，然后说可以的，我要给你发信息啦！
在三次握手之后，A和B都能确定这么一件事：我说的话，你能听到；你说的话，我也能听到。这样，就可以开始正常通信了。
注意：>TCP的报文头：
源端口、目的端口、序列号、确认号、offset、保留域、标志位、滑动窗口大小、校验和、其他的可选参数

TCP Flags中的重要的三个：
ACK：确认序列号标志
SYN：同步序列号，用于建立连接过程
FIN：finish标志，用于释放连接

假设主动发起连接的是客户端
服务器进入listen状态，随时监听客户进程发送的连接请求
客户端向服务器发出连接请求报文，让SYN=1，并且选择一个初始序列号x，发送后客户端进入SYN_SENT的状态（不能携带数据，消耗序列号）
服务器接收到请求报文，如果同意连接，发送一个确认报文，其中ACK和SYN为1，确认号为x+1，并且选择一个序列号y，发送后服务器进入SYN_RCVD的状态（不能携带数据，消耗序列号）
当TCP客户进程收到来自服务端的确认报文后，回馈给服务器一个确认报文，其中ACK=1，确认号是y+1，序列号是x+1，之后进入ESTABLISHED状态（可以携带数据，不携带数据的话不消耗序列号）
服务器收到客户端的确认报文后进入ESTABLISHED状态，连接建立

是三次不是两次：
TCP为了实现数据的有序、可靠传输，需要通信双方都维护一个序列号，告知对方哪些数据已经收到，接下来需要什么数据
三次握手能使通信双方各自向对方发送自己的初始序列号，并且通过对方发来的确认应答确认对方已经收到了自己的序列号
如果是两次握手，只能确保连接发起方的序列号被对方收到，另一方无法得到确认

是三次不是四次：

服务器向客户进程通知它的序列号和确认它已收到客户进程的序列号可以合并

服务器收到客户端的SYN，回复SYN-ACK后，会将与此客户端的连接加入半连接序列，在一段时间内等待这个序列中的客户端回复ACK后，将客户端置入连接序列进行数据传输，如果超时，就会将该链接从半连接序列中删除
如果存在恶意客户端，发送一个SYN后，不回复服务器的SYN-ACK，占据服务器的半连接序列，并且在服务器未删除此半连接状态时，换ip重复发送SYN不回复，就会占满服务器的半连接序列，使得服务器无法与其他客户端进行连接，称为SYN FLOOD攻击

防护措施：如果超时未收到客户端的确认，就每间隔一段时间向客户端发送探测报文，尝试k次后客户端仍然没回应，就中断连接

IP地址唯一标识主机，TCP协议和端口号唯一标识主机中的进程，使用IP地址、协议和端口号，即套接字来实现

假设客户端主动关闭连接

一开始双方都处于ESTABLISHED的状态，首先客户端进程发出连接释放报文，并且停止发送数据，报文中FIN=1，序列号为客户端上一次发送数据的序列号加1，设为u，发送后客户端进入FIN_WAIT_1的状态（消耗序列号，即使不发送数据）
服务器收到客户端的连接释放报文后，向客户端发送一个确认报文，ACK=1，序列号设为v，确认号是u+1，进入CLOSE_WAIT的状态
客户端收到确认报文后进入FIN_WAIT2的状态，服务器继续发送还没发送的数据
服务器发送数据结束后，向客户端发送一个连接释放报文，FIN=1，ACK=1，假设序列号为w，确认号为u+1，之后进入LAST_WAIT状态，等待客户端的确认
客户端收到后，向服务器发送确认报文，ACK=1，序列号u+1，确认号w+1，进入TIME_WAIT状态，如果在这个时间里没有收到服务器的报文，就关闭连接
服务器收到客户端的确认后关闭连接

为什么有TIME_WAIT状态：
保证有足够的时间让对方收到确认报文
假设客户端主动关闭连接，服务器要接收到最后来自客户端的确认报文后才会关闭连接
如果确认报文在传输过程中丢失了，服务器超时未收到确认报文就会向客户端通知自己还需要确认报文，客户端就能在TIME_WAIT时间段里收到通知，重新发送确认报文，直到TIME_WAIT时间段里服务器没有发送通知，说明服务器已收到确认报文后关闭连接

为何四次：
假设客户端主动关闭连接
在客户端发送连接释放报文后，服务器要回复一个确认报文，但此时服务器可能还没有传输完数据，所以服务器会在传输完成之后再发送连接释放报文，再等待客户端回复确认，需要四次握手

服务器出现大量CLOSE WAIT状态的原因
/////////////////////////////////////////////////////////////////

UDP：
面向非连接，传输数据之前，发送方和接收方不建立连接
不需要维护连接，支持同时向多个客户端传输相同的信息
报文结构更简单，开销小
吞吐量只受限于数据生成速率、传输速率以及机器性能
尽最大可能交付，不保证可靠性
面向报文，不对应用程序提交的报文信息进行拆分或合并

区别：
面向连接vs无连接：TCP在传输数据前通过三次握手建立一对一的连接，UDP不需要建立连接，支持一对多、多对一、多对多的传输
可靠性：TCP通过三次握手、重传等机制保证数据传输的可靠性，UDP的数据可能在传输中丢失
有序性：TCP的数据到达可能无序，但是会通过序列号给数据排序，保证其有序性，UDP不具备有序性
速度：TCP需要创建连接、保证数据可靠性和有序性需要做额外的事情，速度更慢，UDP更快，更适合对速度要求高的应用，比如在线视频
量级：TCP的结构更加复杂，UDP更简单，轻量级

确认应答和超时重传：
数据到达接收方，接收方需要发送确认应答，告知对方已经收到数据段，其中的确认序号说明自己下一次需要接受的数据序列号。如果发送方超时未收到确认应答，就进行重传

滑动窗口控制与重复确认应答：
TCP利用滑动窗口提高传输速率，在一个滑动窗口内，不需要等到确认应答就能发送下一段数据，窗口大小是无需等待确认能发送数据大小的最大值，如果不使用滑动窗口，每次收到一个数据都要重发
使用滑动窗口，如果有一段数据丢失，接收方就会反复发送等待该段数据的确认应答，发送端如果收到三次相同的确认应答，就会进行重发。这样的话，如果是确认应答丢失，而数据段并没有丢失，接受方不会重复发送确认应答，就不需要重传，如果数据段丢失，接收方就会一直发送确认应答直到收到该段数据

拥塞控制：
如果一开始把滑动窗口定的太大，发送端发送大量数据，可能造成拥堵，因此，TCP针对这个情况进行拥塞控制
定义拥塞窗口，初始值为1，每次收到一个确认应答，将窗口大小乘2
同时设置了一个阈值，当窗口大小达到阈值后，窗口大小不再以指数增长，而是线性增长，来避免拥塞
如果发生了数据段的超时重传，即发生了拥塞，就把阈值调整为原来的一半，然后将窗口大小重制为1
如果发生了重复确认应答，就立刻重传，并且将阈值设置为原来的一半，将窗口调整为阈值左右的大小

接收方收到数据后，在确认应答中会告知发送方自己接受数据的能力，发送方得到确认应答后根据接收方的接受能力调整发送数据的速率

ip地址：
IP地址是IP协议提供的一种统一的地址格式，位于网络层，为互联网上的每一台主机提供一个逻辑地址

mac地址：
硬件物理地址，用来定义网络设备，位于数据链路层

数据链路层交互过程：
数据链路层以mac地址作为通信目标，数据包到达数据链路层的时候，先查找自己的arp缓存表，看是否存在目的IP的mac地址，有的话就将mac地址封装到包头，否则，发起广播询问目标IP的mac地址，所有收到广播的机器看这个IP是否是自己的，是的话就单播发送mac地址给发送请求的机器

udp 和tcp 是 OSI 模型中的运输层中的协议。tcp 提供可靠的通信传输，而 udp 则常被用于让广播和细节控制交给应用的通信传输。两者的区别大致如下：tcp 面向连接，udp 面向非连接即发送数据前不需要建立连接；tcp 提供可靠的服务（数据传输），udp 无法保证；tcp 面向字节流，udp 面向报文；tcp 数据传输慢，udp 数据传输快；tcp 为什么要三次握手？ 我们假设A和B是通信的双方。我理解的握手实际上就是通信，发一次信息就是进行一次握手。
第一次握手：A给B打电话说，你可以听到我说话吗？第二次握手：B收到了A的信息，然后对A说：我可以听得到你说话啊，你能听得到我说话吗？第三次握手：A收到了B的信息，然后说可以的，我要给你发信息啦！
在三次握手之后，A和B都能确定这么一件事：我说的话，你能听到；你说的话，我也能听到。这样，就可以开始正常通信了。注意：>

在TCP／IP中，TCP协议通过三次握手来建立连接，从而提供可靠的连接服务。

第一次握手：建立连接后，客户端向服务器发送syn包（syn＝j），进入SYN＿SEND状态，等待服务器确认；

第二次握手：当服务器收到syn包时，必须确认客户端的syn（ack＝j＋1）并发送一个syn包（syn＝k），即syn＋ack包。此时，服务器进入SYN＿RECV状态。

第三次握手：SYN＋ACK包，客户端收到服务器端发来的确认包ACK（ACK＝k＋1），来发送这个包来发送，客户端和服务器端进入建立状态，完成三路握手。

扩展资料：

重要概念：

无关的队列：三重握手协议、服务器维护一个独立队列，为每个客户的SYN包创建一个条目（SYN＝j）表明服务器已经收到了SYN包和确认发送到客户，等待客户的确认包。

这些条目标识的连接处于服务器的Syn＿RECV状态，当服务器接收到客户机的确认包时，它将删除该条目，服务器将进入已建立的状态。

Backlog参数：表示要保持的未连接队列的最大数量。

当服务器发送synack包时，如果没有收到客户端确认包，服务器将进行第一次重传，等待一段时间仍然没有收到客户端确认包，然后进行第二次重传。

如果重传号超过系统指定的最大重传号，系统将从半连接队列中删除连接信息。注意每个重传的等待时间可能不相同。

半连接生存时间：指半连接队列中条目的最长生存时间，即从接收SYN包到确认无效消息的最长服务时间。这个时间值是所有重传请求包的最长等待时间的总和。有时我们也称半连接生存时间为超时时间，SYN＿RECV生存时间。

---