第1页 / 共16页
第2页 / 共16页
第3页 / 共16页
第4页 / 共16页
第5页 / 共16页
第6页 / 共16页
第7页 / 共16页
第8页 / 共16页
计算机网络基础.docx
计算机网络基础
1.0、TCP的三次握手和四次挥手
1.1、为什么要三次握手？为什么不是四次？
1.2、为什么要四次挥手？详解一下四次挥手的各步骤状态
1.3、TCP怎么保证可靠性？
1.4、TCP的拥塞控制
1.9、TCP和UDP的区别和各自适用的场景
1.5、OSI七层模型 TCP/IP四层模型
1.6、TCP/IP数据链路层的交互过程
1.7、超时重传机制
1.8、快速重传机制
1.9、建立了TCP连接后，客户端突然出现故障了怎么办？
1.10、为什么TIME_WAIT?
1.11、为什么TIME_WAIT是2MSL？
1.12、每次握手失败对应的措施
2.1、UDP的特点
2.2、UDP的单播、多播、广播、组播
2.3、介绍一下udp的connect函数
2.4、UDP的使用场景
3.0、HTTP协议
3.1、HTTP协议的特点
3.2、HTTP请求/响应的步骤（输入XXX.com）
3.3、HTTP和HTTPS的区别，以及HTTPS有什么缺点？
3.4、HTTP返回码
3.6、HTTP 1.0，1.1和2.0的区别
3.5、GET和POST的区别
4.0、socket编程中服务器端和客户端主要用到哪些函数？
4.2、Socket编程的send() 、recv() 、accept() 、socket()函数？
4.3、长连接和短连接
5.0、搜索baidu，会用到计算机网络中的什么层？每层是干什么的
5.1、数字证书是什么，里面都包含那些内容？
5.2、对称加密和非对称加密
6.0、路由器、交换机、集线器
6.1、路由器和防火墙
6.3、IPv4 和 IPv6
1.0、TCP 的三次握手和四次挥手
计算机网络基础
三次握手：
1. Client 将标志位 SYN 置为 1，随机产生一个值 seq=J，并将该数据包发送给 Server，Client 进入 SYN_SENT 状态，
等待 Server 确认。
2. Server 收到数据包后由标志位 SYN=1 知道 Client 请求建立连接，Server 将标志位 SYN 和 ACK 都置为 1，ack=J+1，
随机产生一个值 seq=K，并将该数据包发送给 Client 以确认连接请求，Server 进入 SYN_RCVD 状态。
3. Client 收到确认后，检查 ack 是否为 J+1，ACK 是否为 1，如果正确则将标志位 ACK 置为 1，ack=K+1，并将该数据
包发送给 Server，Server 检查 ack 是否为 K+1，ACK 是否为 1，如果正确则连接建立成功，Client 和 Server 进入
ESTABLISHED 状态，完成三次握手，随后 Client 与 Server 之间可以开始传输数据了。
四次挥手：
由于 TCP 连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送
一个 FIN 来终止这一方向的连接，收到一个 FIN 只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在
这个 TCP 连接上仍然能够发送数据，直到这一方向也发送了 FIN。首先进行关闭的一方将执行主动关闭，而另一方则执
行被动关闭。
1.数据传输结束后，客户端的应用进程发出连接释放报文段，并停止发送数据，客户端进入 FIN_WAIT_1 状态，此时客
户端依然可以接收服务器发送来的数据。
2.服务器接收到 FIN 后，发送一个 ACK 给客户端，确认序号为收到的序号+1，服务器进入 CLOSE_WAIT 状态。客户端
收到后进入 FIN_WAIT_2 状态。
3.当服务器没有数据要发送时，服务器发送一个 FIN 报文，此时服务器进入 LAST_ACK 状态，等待客户端的确认
4.客户端收到服务器的 FIN 报文后，给服务器发送一个 ACK 报文，确认序列号为收到的序号+1。此时客户端进入
TIME_WAIT 状态，等待 2MSL（MSL：报文段最大生存时间），然后关闭连接。
1.1、为什么要三次握手？为什么不是四次？
三次握手的原因：
三次握手可以防止已经失效的连接请求报文突然又传输到服务器端导致的服务器资源浪费。例如，客户端先发送了
一个 SYN，但是由于网络阻塞，该 SYN 数据包在某个节点长期滞留。然后客户端又重传 SYN 数据包并正确建立 TCP
连接，然后传输完数据后关闭该连接。该连接释放后失效的 SYN 数据包才到达服务器端。在二次握手的前提下，服务器
端会认为这是客户端发起的又一次请求，然后发送 SYN ，并且在服务器端创建 socket 套接字，一直等待客户端发送数
据。但是由于客户端并没有发起新的请求，所以会丢弃服务端的 SYN 。此时服务器会一直等待客户端发送数据从而造成
资源浪费。
为什么不是四次握手：
本来握手应该和挥手一样都是需要确认两个方向都能联通的，本来模型应该是：
1.客户端发送 syn0 给服务器
2.服务器收到 syn0，回复 ack(syn0+1)
3.服务器发送 syn1
4.客户端收到 syn1，回复 ack(syn1+1)
因为 TCP 是全双工的，上边的四部确认了数据在两个方向上都是可以正确到达的，但是 2，3 步没有上下的联系，
可以将其合并，加快握手效率，所有就变成了 3 步握手。
1.2、为什么要四次挥手？详解一下四次挥手的各步骤状态
因为当 Server 端收到 Client 端的 SYN 连接请求报文后，可以直接发送 SYN+ACK 报文。其中 ACK 报文是用来应答
的，SYN 报文是用来同步的。但是关闭连接时，当 Server 端收到 FIN 报文时，很可能并不会立即关闭 SOCKET，所以
只能先回复一个 ACK 报文，告诉 Client 端，"你发的 FIN 报文我收到了"。只有等到我 Server 端所有的报文都发送完了，
我才能发送 FIN 报文，因此不能一起发送。故需要四步握手。
FIN_WAIT_1:
这个状态和 FIN_WAIT_2 状态都在再等待对方的回复，但是这两种状态是有区别的,FIN_WAIT_1 就是主动
方在 ESTABLISHED 状态的时候，想要主动关闭连接，向对方发送 FIN 报文，这时候就进入了 FIN_WAIT_1
状态。当他收到对方回复的 ACK 报文后，就进入了 FIN_WAIT_2 状态。 但是在实际操作中是很难遇到
FIN_WAIT_1 状态的，因为无论对方是什么情况都应该立刻回应 ACK 报文，但是 FIN_WAIT_2 状态还是可以
在主动方中用 netstat 看到的。
FIN_WAIT_2：
上面已经对 FIN_WAIT_2 讲解过了，当主动方进入 FIN_WAIT_2 时，就表示着半连接状态，也就是主动方
还有数据要发给对方，这个数据就是之后的 ACK，所有他要等一会儿才关闭连接。
CLOSE_WAIT：
这个状态从表面也可以看出它的作用，就是等待关闭。当被动方接收到 FIN 时，会立刻回复一个 ACK 给
对方，接下来就是进入 CLOSE_WAIT 状态。在这个状态中，被动方需要考虑自己还有没有数据要发送给对方，
如果有可以继续发送，如果没有了就可以关闭连接了，发送一个 FIN 给对方。 这个状态其实也就是给自己一个
缓冲的时间，让自己处理完需要处理的事，然后去关闭连接。
TIME_WAIT：
这个状态就是一段时间后进行一些操作。当主动方收到了对方发来的 FIN 报文，并发出 ACK 报文，接下
来就等 2MSL 就可以进入 CLOSED 状态了。其实，如果主动方在 FIN_WAIT_1 状态下，收到了对方的 FIN+ACK
标志的报文，就可以跳过 FIN_WAIT_2 状态直接进入 TIME_WAIT 状态了。
LAST_ACK：
这个状态从表面不难不理解他的意思，这个状态就是被动方发送了 FIN 报文后，最后等待对方的 ACK 报
文，收到 ACK 报文后就可以进入 CLOSED 状态了。
CLOSED：
上面提到了几次这个状态，相比也猜出来了，这个状态表示的就是连接中断，已经关闭。
1.3、TCP 怎么保证可靠性？
（1）序列号、确认应答、超时重传
数据到达接收方，接收方需要发出一个确认应答，表示已经收到该数据段，并且确认序号会说明了它下一次需
要接收的数据序列号。如果发送发迟迟未收到确认应答，那么可能是发送的数据丢失，也可能是确认应答丢失，这
时发送方在等待一定时间后会进行重传。这个时间一般是 2*RTT(报文段往返时间）+一个偏差值。
（2）窗口控制与高速重发控制/快速重传（重复确认应答）
TCP 会利用窗口控制来提高传输速度，意思是在一个窗口大小内，不用一定要等到应答才能发送下一段数据，
窗口大小就是无需等待确认而可以继续发送数据的最大值。如果不使用窗口控制，每一个没收到确认应答的数据都
要重发。
使用窗口控制，如果数据段 1001-2000 丢失，后面数据每次传输，确认应答都会不停地发送序号为 1001 的应
答，表示我要接收 1001 开始的数据，发送端如果收到 3 次相同应答，就会立刻进行重发；但还有种情况有可能是
数据都收到了，但是有的应答丢失了，这种情况不会进行重发，因为发送端知道，如果是数据段丢失，接收端不会
放过它的，会疯狂向它提醒......
（3）拥塞控制
如果把窗口定的很大，发送端连续发送大量的数据，可能会造成网络的拥堵（大家都在用网，你在这狂发，吞
吐量就那么大，当然会堵），甚至造成网络的瘫痪。所以 TCP 在为了防止这种情况而进行了拥塞控制。
慢启动：定义拥塞窗口，一开始将该窗口大小设为 1，之后每次收到确认应答（经过一个 rtt），将拥塞窗口*2。
拥塞避免：设置慢启动阈值，一般开始都设为 65536。拥塞避免是指当拥塞窗口大小达到这个阈值，拥塞窗口
的值不再指数上升，而是加法增加（每次确认应答/每个 rtt，拥塞窗口大小+1），以此来避免拥塞。
将报文段的超时重传看做拥塞，则一旦发生超时重传，我们需要先将阈值设为当前窗口大小的一半，并且将窗
口大小设为初值 1，然后重新进入慢启动过程。
快速重传：在遇到 3 次重复确认应答（高速重发控制）时，代表收到了 3 个报文段，但是这之前的 1 个段丢失
了，便对它进行立即重传。
然后，先将阈值设为当前窗口大小的一半，然后将拥塞窗口大小设为慢启动阈值+3 的大小。
这样可以达到：在 TCP 通信时，网络吞吐量呈现逐渐的上升，并且随着拥堵来降低吞吐量，再进入慢慢上升的
过程，网络不会轻易的发生瘫痪。
1.4、TCP 的拥塞控制
拥塞控制是防止过多的数据注入网络，使得网络中的路由器或者链路过载。流量控制是点对点的通信量控制，而拥
塞控制是全局的网络流量整体性的控制。发送双方都有一个拥塞窗口——cwnd。
1、慢开始
最开始发送方的拥塞窗口为 1，由小到大逐渐增大发送窗口和拥塞窗口。每经过一个传输轮次，拥塞窗口 cwnd
加倍。当 cwnd 超过慢开始门限，则使用拥塞避免算法，避免 cwnd 增长过大。
2、拥塞避免
每经过一个往返时间 RTT，cwnd 就增长 1。
在慢开始和拥塞避免的过程中，一旦发现网络拥塞，就把慢开始门限设为当前值的一半，并且重新设置 cwnd 为 1，
重新慢启动。（乘法减小，加法增大）
3、快重传
接收方每次收到一个失序的报文段后就立即发出重复确认，发送方只要连续收到三个重复确认就立即重传（尽
早重传未被确认的报文段）。
4、快恢复
当发送方连续收到了三个重复确认，就乘法减半（慢开始门限减半），将当前的 cwnd 设置为慢开始门限，并
且采用拥塞避免算法（连续收到了三个重复请求，说明当前网络可能没有拥塞）。
采用快恢复算法时，慢开始只在建立连接和网络超时才使用。
采用慢开始和拥塞避免算法的时候
1. 一旦 cwnd>慢开始门限，就采用拥塞避免算法，减慢增长速度
2. 一旦出现丢包的情况，就重新进行慢开始，减慢增长速度
采用快恢复和快重传算法的时候
1. 一旦 cwnd>慢开始门限，就采用拥塞避免算法，减慢增长速度
2. 一旦发送方连续收到了三个重复确认，就采用拥塞避免算法，减慢增长速度
1.9、TCP 和 UDP 的区别和各自适用的场景
TCP
TCP 是面向连接的传输层协议
点对点的两点间服务，一条 TCP 连接只能有两个端点
可靠交付：无差错，不丢失，不重复，按序到达
有拥塞控制和流量控制保证数据传输的安全性
动态报文长度，即 TCP 报文长度是根据接收方的窗口大小
和当前网络拥塞情况决定的
首部开销大，首部 20 个字节
UDP
UDP 无连接
UDP 支持一对一，一对多，多对一，多对多的交互通信
尽最大努力交付，不保证可靠交付
没有拥塞控制，网络拥塞不会影响源主机的发送效率
面向报文，不合并，不拆分，保留上面传下来报文的边界
首部开销小，8 字节。（源端口，目的端口，数据长
度，校验和）
TCP 和 UDP 适用场景
从特点上我们已经知道，TCP 是可靠的但传输速度慢，UDP 是不可靠的但传输速度快。因此在选用具体协议通信
时，应该根据通信数据的要求而决定。
若通信数据完整性需让位与通信实时性，则应该选用 TCP 协议（如文件传输、重要状态的更新等）；反之，则使用
UDP 协议（如视频传输、实时通信等）。
1.5、OSI 七层模型
TCP/IP 四层模型
OSI 七层模型：
物理层:
通过媒介传输比特,确定机械及电气规范,传输单位为 bit，主要包括的协议为：IEE802.3 CLOCK RJ45
数据链路层:
将比特组装成帧和点到点的传递,传输单位为帧,主要包括的协议为 MAC VLAN PPP
网络层：
负责数据包从源到宿的传递和网际互连，传输单位为包,主要包括的协议为 IP ARP ICMP
传输层：
提供端到端的可靠报文传递和错误恢复，传输单位为报文,主要包括的协议为 TCP UDP
会话层：
建立、管理和终止会话，传输单位为 SPDU，主要包括的协议为 RPC NFS
表示层:
对数据进行翻译、加密和压缩,传输单位为 PPDU，主要包括的协议为 JPEG ASII
应用层:
允许访问 OSI 环境的手段,传输单位为 APDU，主要包括的协议为 FTP HTTP DNS
TCP/IP 4 层模型包括：
网络接口层：MAC VLAN
网络层:IP ARP ICMP
传输层:TCP UDP
应用层:HTTP DNS SMTP
1.6、TCP/IP 数据链路层的交互过程
网络层等到数据链层用 mac 地址作为通信目标，数据包到达网络等准备往数据链层发送的时候，首先会去自己的 arp
缓存表(存着 ip-mac 对应关系)去查找改目标 ip 的 mac 地址，如果查到了，就讲目标 ip 的 mac 地址封装到链路层数据包
的包头。如果缓存中没有找到，会发起一个广播：who is ip XXX tell ip XXX,所有收到的广播的机器看这个 ip 是不是自己
的，如果是自己的，则以单拨的形式将自己的 mac 地址回复给请求的机器
1.7、超时重传机制
超时重传指的是，发送数据包在一定的时间周期内没有收到相应的 ACK，等待一定的时间，超时之后就认为这
个数据包丢失，就会重新发送。这个等待时间被称为 RTO.
检测丢失 segment 的方法从概念上讲还是比较简单的，每一次开始发送一个 TCP segment 的时候，就启动重
传定时器，定时器的时间一开始是一个预设的值（Linux 规定为 1s），随着通讯的变化以及时间的推移，这个定时
器的溢出值是不断变化的，如果在 ACK 收到之前，定时器到期，协议栈就会认为这个片段被丢失，重新传送数据。
重传原则：
1 .这些被发送的片段放在一个窗口中，等待被确认，没有确认不会从窗口中移走，定时器在重传时间到期内，
每个片段的位置不变，这个地方其实在滑动窗口的时候也有提到过
2 .只有等到 ACK 收到的时候，变成发送并 ACK 的片段，才会被从窗口中移走。
3 .如果定时器到期没有收到对应 ACK， 就重传这个 TCP segment
1.8、快速重传机制
在超时重传中，重点是定时器溢出超时了才认为发送的数据包丢失，快速重传机制，实现了另外的一种丢包评
定标准，即如果我连续收到 3 次 ACK，发送方就认为这个 seq 的包丢失了，立刻进行重传，这样如果接收端回复及
时的话，基本就是在重传定时器到期之前，提高了重传的效率。
在传输过程中会出现 out-of-order 的现象，但是在滑动窗口中会有严格的顺序控制，假设有 4，5，6 三个待接
收的数据包，先收到了 5,6，协议栈是不会回复对 5,6 包的确认，而是根据 TCP 协议的规定，当接收方收到乱序片
段时，需要重复发送 ACK, 在这个地方会发送报文 4 seq 的 ACK，表明需要报文 4 没有被接收到，如果此后收到的
是报文 7，那么仍然要回报文 4 seq 的 ACK，如果连续发送 3 个 ACK，接收端认为这个片段已经丢失，进行快速重
传。
1.9、建立了 TCP 连接后，客户端突然出现故障了怎么办？
TCP 还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到
一次客户端的请求后都会重新复位这个计时器，时间通常是设置为 2 小时，若两小时还没有收到客户端的任何数据，服
务器就会发送一个探测报文段，以后每隔 75 秒钟发送一次。若一连发送 10 个探测报文仍然没反应，服务器就认为客户
端出了故障，接着就关闭连接。
1.10、为什么 TIME_WAIT?
TIME_WAIT 在四次挥手中有着不可替代的位置，如果没有 TIME-WAIT，主动方就会直接进入 CLOSED 状态，
（假设主动方时客户端，被动方时服务端）这时候如果立即重启客户端使用相同的端口，如果因为网络中种种原因最后
一次 ACK 丢失了，服务端就会重复 FIN 请求，这时这个 FIN 就会被重新启动的客户端接收到，或者新启动的客户端向服
务端发起请求的时候，因为服务端正在等待最后一次 ACK，因此新连接请求发送的 SYN 就会被服务端认为时请求码错
误，服务端就会回复 RET 重置连接。所以就需要主动方发送最后一次 ACK 之后进入 TIME_WAIT 状态，等待 2MSL（两
个报文最大生命周期），等待这段时间就是为了如果接收到了重发的 FIN 请求能够进行最后一次 ACK 回复，让在网络中
延迟的 FIN/ACK 数据都消失在网络中，不会对后续连接造成影响
1.11、为什么 TIME_WAIT 是 2MSL？
MSL（Maximum Segment Lifetime）是 TCP 报文的最大生命周期，因为 TIME_WAIT 持续在 2MSL 就可以保证在
两个传输方向上的尚未接收到或者迟到的报文段已经消失，否则服务器立即重启，可能会收到来自上一个进程迟到的数
据，但是这种数据很可能是错误的，同时也是在理论上保证最后一个报文可靠到达，假设最后一个 ACK 丢失，那么服务
器会再重发一个 FIN，这是虽然客户端的进程不在了，但是 TCP 连接还在，仍然可以重发 LAST_ACK。
1.12、每次握手失败对应的措施
第一次握手失败：
如果第一次的 SYN 传输失败，两端都不会申请资源。如果一段时间后之前的 SYN 发送成功了，这时客户端只会
接收他最后发送的 SYN 的 SYN+ACK 回应，其他的一概忽略，服务端也是如此，会将之前多申请的资源释放了。
第二次握手失败：
如果服务端发送的 SYN+ACK 传输失败，客户端由于没有收到这条响应，不会申请资源，虽然服务端申请了资源，
但是迟迟收不到来自客户端的 ACK，也会将该资源释放。
第三次握手失败:
如果第三次握手的 ACK 传输失败，导致服务端迟迟没有收到 ACK，就会释放资源，这时候客户端认为自己已经
连接好了，就会给服务端发送数据，服务端由于没有收到第三次握手，就会以 RST 包对客户端响应。但是实际
上服务端会因为没有收到客户端的 ACK 多次发送 SYN+ACK，次数是可以设置的，如果最后还是没有收到客户端
的 ACK，则释放资源。
2.1、UDP 的特点
UDP 协议在 IP 协议上增加了复用、分用和差错检测功能。UDP 的特点：
1、是无连接的。相比于 TCP 协议，UDP 协议在传送数据前不需要建立连接，当然也就没有释放连接。
2、是尽最大努力交付的。也就是说 UDP 协议无法保证数据能够准确的交付到目的主机。也不需要对接收到的 UDP
报文进行确认。
3、是面向报文的。也就是说 UDP 协议将应用层传输下来的数据封装在一个 UDP 包中，不进行拆分或合并。因此，
运输层在收到对方的 UDP 包后，会去掉首部后，将数据原封不动的交给应用进程。
4、没有拥塞控制。因此 UDP 协议的发送速率不送网络的拥塞度影响。
5、UDP 支持一对一、一对多、多对一和多对多的交互通信。
6、UDP 的头部占用较小，只占用 8 个字节。
2.2、UDP 的单播、多播、广播、组播
假设 A(all 简写)代表所有的机器，M(multiple 简写)代表 A 中的多个机器，G(group 简写)代表一组机器，1 代表一台
机器，那么：
1 -> 1 就是单播；
1 -> M 就是多播；
1 -> A 就是广播；
1 -> G 就是组播；
当 M=A 时，多播就是广播；
当 M=G 时，多播就是组播；
多播包括组播和广播，组播、广播都是多播的一种表现形式。
单播
单播是主机之间“一对一”的通讯模式。发送方需要指定一个接收方的 IP 和端口，只有这个接收方会收到数据
报。不会对子网内的其他机器产生影响。
在单播模式下，服务器针对每个客户机都要发送数据流，服务器流量=客户机数量×客户机流量，在客户机数量
大、每个客户机流量大的应用（如流媒体）中，服务器将不堪重负。
广播
广播是主机之间“一对所有”的通讯模式。子网的一台主机作为发送发广播一条信息，该子网中的所有主机都
可以接收到该信息（不管你是否需要该信息）。
在广播模式下，由于服务器不用向每个客户机单独发送数据，所以服务器流量负载极低。
无法在广域网上进行广播，而且广播消息不会被路由转发，所以只能在一个子网中进行广播。因为如果路由器
转发了广播信息，那么势必会引起网络瘫痪。这也是为什么 IP 协议的设计者故意没有定义互联网范围的广播机制。
主机发送广播消息时，需要指定目的 IP 地址为 255.255.255.255 和接受者的端口号。
组播
组播是主机之间“一对多”的通讯模式。一台主机加入一个组播 IP 后，之后向该组播 IP 发送的数据报都会发
送到该主机。
专门为组播划出了一个地址范围，在 IPv4 中为 D 类地址，范围是 224.0.0.0 ~ 239.255.255.255，并将 D 类地
址划分为局部链接组播地址、预留组播地址、管理权限组播地址如下：
局部链接地址：224.0.0.0～224.0.0.255，用于局域网，路由器不转发属于此范围的 IP 包。
预留组播地址：224.0.1.0～238.255.255.255，用于全球范围或网络协议。
管理权限地址：239.0.0.0～239.255.255.255，组织内部使用，用于限制组播范围。
2.3、介绍一下 udp 的 connect 函数
除非套接字已连接，否则异步错误是不会反悔到 UDP 套接字的。我们确实可以给 UDP 套接字调用 connect，然而
这样做的结果却与 TCP 连接不同的是没有三路握手过程。内核只是检查是否存在立即可知的错误，记录对端的 IP 地址
和端口号，然后立即返回调用进程。
对于已连接 UDP 套接字，与默认的未连接 UDP 套接字相比，发生了三个变化。
其实一旦 UDP 套接字调用了 connect 系统调用，那么这个 UDP 上的连接就变成一对一的连接，但是通过这个 UDP
连接传输数据的性质还是不变的，仍然是不可靠的 UDP 连接。一旦变成一对一的连接，在调用系统调用发送和接受数据
时也就可以使用 TCP 那一套系统调用了。
1、我们再也不能给输出操作指定目的 IP 地址和端口号。也就是说，我们不使用 sendto，而改用 write 或 send。写到已
连接 UDP 套接字上的任何内容都自动发送到由 connect 指定的协议地址。可以给已连接的 UDP 套接字调用 sendto，
但是不能指定目的地址。sendto 的第五个参数必须为空指针，第六个参数应该为 0.
2、不必使用 recvfrom 以获悉数据报的发送者，而改用 read、recv 或 recvmsg。在一个已连接 UDP 套接字上，由内核
为输入操作返回的数据报只有那些来自 connect 指定协议地址的数据报。这样就限制一个已连接 UDP 套接字能且仅
能与一个对端交换数据报。
3、由已连接 UDP 套接字引发的异步错误会返回给它们所在的进程，而未连接的 UDP 套接字不接收任何异步错误。
来自任何其他 IP 地址或断开的数据报不投递给这个已连接套接字，因为它们要么源 IP 地址要么源 UDP 端口不与该
套接字 connect 到的协议地址相匹配。
UDP 客户进程或服务器进程只在使用自己的 UDP 套接字与确定的唯一对端进行通信时，才可以调用 connect。调用
connect 的通常是 UDP 客户，不过有些网络应用中的 UDP 服务器会与单个客户长时间通信 TFTP，这种情况下，客户和
服务器都可能调用 connect。
2.4、UDP 的使用场景
在选择使用协议的时候，选择 UDP 必须要谨慎。在网络质量令人十分不满意的环境下，UDP 协议数据包丢失会比
较严重。但是由于 UDP 的特性:它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频
和普通数据在传送时使用 UDP 较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。比如我们
聊天用的 QQ 就是使用的 UDP 协议。
既然 UDP 是一种不可靠的网络协议，那么还有什么使用价值或必要呢?其实不然，在有些情况下 UDP 协议可能会变
得非常有用。因为 UDP 具有 TCP 所望尘莫及的速度优势。虽然 TCP 协议中植入了各种安全保障功能，但是在实际执行
的过程中会占用大量的系统开销，无疑使速度受到严重的影响。反观 UDP 由于排除了信息可靠传递机制，将安全和排序
等功能移交给上层应用来完成，极大降低了执行时间，使速度得到了保证。
3.0、HTTP 协议
1、HTTP 协议是 Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网（WWW:World Wide Web）
服务器传输超文本到本地浏览器的传送协议。
2、HTTP 是一个基于 TCP/IP 通信协议来传递数据（HTML 文件，图片文件，查询结果等）。
3、HTTP 是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系 统。它于 1990
年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在 WWW 中使用的是
4、HTTP 协议工作于客户端-服务端架构为上。浏览器作为 HTTP 客户端通过 URL 向 HTTP 服务端即 WEB 服务器发送
所有请求。Web 服务器根据接收到的请求后，向客户端发送响应信息。
3.1、HTTP 协议的特点
1、简单快速：
客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有 GET、HEAD、POST。每种方法规定了
客户与服务器联系的类型不同。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。
2、灵活：
HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。
3、无连接：
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采
用这种方式可以节省传输时间。
4、无状态：
HTTP 协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的
信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答
就较快。
5、支持 B/S 及 C/S 模式。
6、默认端口 80
7、基于 TCP 协议
3.2、HTTP 请求/响应的步骤（输入 XXX.com）
1、客户端连接到 Web 服务器
一个 HTTP 客户端，通常是浏览器，与 Web 服务器的 HTTP 端口（默认为 80）建立一个 TCP 套接字连接。例如，
http://www.baidu.com。
2、发送 HTTP 请求
通过 TCP 套接字，客户端向 Web 服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请
求数据 4 部分组成。
3、服务器接受请求并返回 HTTP 响应
Web 服务器解析请求，定位请求资源。服务器将资源复本写到 TCP 套接字，由客户端读取。一个响应由状态行、响
应头部、空行和响应数据 4 部分组成。
4、释放连接 TCP 连接
若 connection 模式为 close，则服务器主动关闭 TCP 连接，客户端被动关闭连接，释放 TCP 连接;若 connection 模
式为 keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;
5、客户端浏览器解析 HTML 内容
客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若
干字节的 HTML 文档和文档的字符集。客户端浏览器读取响应数据 HTML，根据 HTML 的语法对其进行格式化，并在浏
览器窗口中显示。
举例：
在浏览器地址栏键入 URL，按下回车之后会经历以下流程：
1、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址；
2、解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立 TCP 连接；
3、浏览器发出读取文件（URL 中域名后面部分对应的文件）的 HTTP 请求，该请求报文作为 TCP 三次握手的第三个
报文的数据发送给服务器；
4、服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器；
5、释放 TCP 连接；
6、浏览器将该 html 文本并显示内容；
3.3、HTTP 和 HTTPS 的区别，以及 HTTPS 有什么缺点？
HTTP 协议和 HTTPS 协议区别如下：
1）HTTP 协议是以明文的方式在网络中传输数据，而 HTTPS 协议传输的数据则是经过 TLS 加密后的，HTTPS 具
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
