计算机网络面经——计算机网络详细知识点
Posted GuochaoHN
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了计算机网络面经——计算机网络详细知识点相关的知识，希望对你有一定的参考价值。
计算机网络体系结构
随着互联网的发展，某些应用程序可以直接使用IP层，甚至直接使用最下面的网络接口层。（例如：分组网间探测PING，用来测试两台主机之间的连通性。PING使用了ICMP回送请求与回送回答报文。）
各层简介：
应用层：
应用层的任务是通过应用进程间的交互来完成特定网络应用。
应用层协议定义的是应用进程间通信和交互的规则。（DNS,HTTP,SMTP等）
运输层：
运输层的任务就是负责向两台主机中进程之间的通信提供通用的数据传输服务。
主要使用以下两种协议
(传输控制协议TCP、用户数据报协议UDP)
网络层：
网络层负责为分组交换网上的不同主机提供通信服务（IP协议）
数据链路层：
负责互联设备之间传送和识别数据帧（数据帧与比特流之间的转换）
物理层：
负责比特流与电子信号之间的转换
网络接口层
物理层
物理层考虑的是怎样才能在连接各种计算机的传输媒体上传输数据比特流，而不是指具体的传输媒体。
物理层主要任务可以认为是确定与传输媒体的接口有关的一些特性：接口电压、形状尺寸、引脚数目等等。
物理层将网络互相连接起来使用的中间设备是转发器
数据链路层
计算机与外界局域网的通信要通过网络适配器，他又称网络接口卡或网卡。计算机的硬件地址就在适配器的ROM中。以太网的硬件地址，即MAC地址实际上就是适配器地址，与主机所在的地点无关。源地址和目标地址都是48位长。
发送数据时：
数据链路将网络层交下来的IP数据报组装成帧。 每一帧包括数据和必要的控制信息（同步信息、地址信息：发送端MAC地址、差错控制等）
接收数据时：
接收端可以根据控制信息知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可以从中提取出数据部分，上交给网络层。
根据包的结构图可以看出，在数据链路层是通过包头中接收端的MAC地址来判断是否是发送给自己的数据包。进而判断是否接受。
而且控制信息还使接收端能够检测到所收到的帧中有无差错。
现实的通信链路不理想，也就说，比特在传输过程中可能会产生比特差错（1可变成0，0可变成1）。如有差错，将简单的丢弃这个差错帧，以免继续在网络中传送下去白白浪费网络资源。
采用CRC循环冗余检验技术可以做到对帧的无差错接受， 而帧检验序列FCS就是添加在数据包后面的冗余码。
注意：只能保证收到的帧是比特没有出现差错的，但无法确定收到的帧是否重复了、缺失了、或是失序了。（提供的是不可靠的传输）
数据链路层将网络互相连接起来的中间设备叫做网桥或桥接器
网络层（IP协议）
互联网采用的设计思路：网络层向上只提供简单灵活的、无连接的、尽最大努力交付的数据报服务（IP数据报）.
网络在发送分组时不需要先建立连接。每一个分组独立发送，也不进行编号。网络层不提供服务质量的承诺。也就是说，所传送的分组可能出错、丢失、失序，当然也不保证分组交付的时限。这种不可靠传输服务，就使得网络中的路由去比较简单，且价格低廉。
网际协议IP
IPv4
长度为四个字节，32位。
IP分类：
网络号为127保留作为本地软件测试环回地址。若主机发送一个目的地址为环回地址的IP数据报，则本机中的协议软件就处理数据报中的数据，而不会把数据报发送到任何网络。目的地址为环回地址的IP数据报永远不会出现在任何网络上，因为网络号127的地址根本不是一个网络地址。
工作流程：通过路由器的路由转发表一级一级不断改写为下一跳IP和MAC地址，最终的找到目标IP和目标MAC地址。
IPv6
IPv4的地址耗尽，ISP已经不能再申请新的IP地址块了。所以采用具有更大地址空间的新版本IP，即IPv6,。
IPv6把地址从32位扩大到128位。
地址解析协议ARP
ARP协议的用途是为了从网络层使用的IP地址，解析出在数据链路层使用的硬件地址。
网络层使用的是IP地址，但在实际的网络的链路上传送数据帧时，最终还是必须使用该网络的硬件地址。
工作原理：
每一台主机都设有一个ARP高速缓存，里面有本局域网上的各主机和路由器的IP地址到硬件地址的映射表，并且这个表还经常动态更新。
当主机A要向本局域网上的某台主机B发送IP数据报
1、先在其ARP高速缓存中查看有无主机B的IP地址。如有，就在表中查出对应硬件地址然后写入MAC帧，最后通过局域网把该MAC帧发往此硬件地址。
2、如果查不到主机B的IP地址项。可能是主机B刚入网，也可能主机A刚加电，高速缓存还是空的。这种情况下，主机A自动运行ARP广播，然后B单播响应A. 最后A获得了B的MAC地址。
网际控制报文协议ICMP
为了更有效地转发IP数据报和提高交付成功的机会，在网际层使用了ICMP协议。ICMP协议允许主机或路由器报告差错情况和提供有关异常情况的报告。ICMP协议是IP层协议，不是高层协议，因为ICMP是作为数据部分装在IP数据报中的。
ICMP应用：
1、分组网间探测PING，用来测试两台主机之间的连通性。PING使用了ICMP回送请求与回送回答报文。
2、traceroute
运输层（TCP、UDP协议）
网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。（真正通信的的实体是两台主机中的应用进程，IP协议只是把分组送到目的主机，但是还没有交付主机中的应用进程）
运输层的端口
TCP/IP的运输层用一个16位端口号来标志一个端口。端口号只具有本地意义，是为了标志本计算机应用层中的各个进程在运输层交互时的层间接口。不同计算机中，相同的端口号是没有关联的。16位端口号可以允许65535个不同的端口号。
根据应用程序的不同要求，运输层需要有两种不同的运输协议。即面向连接的TCP和无连接的UDP。 UDP直接通过端口号确定应用进程，TCP通过套接字确定进程。
① 用户数据报协议UDP
UDP特点：
1、无连接的 ，即发送数据前不需要建立连接，因此减少了开销和发送数据之前的时延。
2、不可靠交付，使用尽最大努力交付。
3、面向报文，应用层交给UDP多长的报文，UDP就照发送，即一次发送一个报文，既不合并，也不拆分。由应用程序选择合适长度报文。
4、没有拥塞控制，网络出现拥塞不会使源主机发送速率降低，适用于某些实时应用，例如IP电话、实时视频会议等，要求源主机以恒定速率发送数据，并且允许在网络发生拥塞时丢失一些数据。
4、支持一对一、一对多、多对一、和多对多的交互通信。
当运输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应端口上交最终的应用进程。
如果接收方UDP发现收到的报文中的目的端口号不正确（即不存在对应于该端口号的应用进程），就丢弃该报文，并由ICMP发送端口不可达差错报文给发送方。
②传输控制协议TCP
TCP特点：
1、是面向连接的运输层协议。使用前必须建立TCP连接，传送数据完毕后，必须释放TCP连接。
2、每条TCP连接只能有两个端点。
3、提供可靠交付的服务。 通过TCP连接传送的数据，无差错、不丢失、不重复，且按顺到达。
4、TCP提供全双工通信。TCP连接的两端都设有发送和接收缓存，允许双发任何时间发送和接收数据。
TCP连接端点（套接字）
套接字socket=（IP地址:端口号）
同一个IP地址可以有多个不同的TCP连接；
同一个端口号也可以出现在多个不同的TCP连接中：
eg：用百度浏览器t同时打开淘宝和京东网页。
网页默认端口号为80.
socket1=（淘宝IP:80），socket2=（京东IP:80）
TCP连接（三次握手）
在双方套接字刚刚创建完成的时候，里面并没有存放任何数据，也不知道通信的对象是谁。
请求端：只有浏览器器知道必要的通信信息(对象IP，端口号等)，但这些信息还没有传递给协议栈。
服务端：应用程序根本不知道通信对象是谁，只有等待请求连接。
连接阶段的任务：
1.请求端：把服务器的IP地址和端口号告知协议栈。
2.客户端向服务器传达开始通信的请求。
连接过程：三次握手
参考博客： https://blog.csdn.net/baiyan3212/article/details/81302448.
第一次握手： 客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN。此时客户端处于 SYN_SENT 状态。
首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。
第二次握手： 服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。
在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。此报文段也不能携带数据（第一次请求端将信息发来之后，服务器端就知道了请求端的IP地址，端口号等通信控制信息）
第三次握手： 客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。
确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。
ack：确认编号，即接收到的上一次远端主机传来的seq然后+1，再发送给远端主机。提示远端主机已经成功接收上一次所有数据。
ACK:确认值，为1表示确认连接。
为什么要第三次握手
第一次握手：客户端发送网络包，服务端收到了。
这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。
这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。
原因一：这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
双方都必须确认自己和对方的发送和接收能力都是正常的。
原因二：防止已经失效的连接请求报文段突然又传到B，因而产生错误。
即：通过请求方的第二次回应报文，确保发来的连接请求是实时的请求，而不是过期的无效的请求报文。
三次握手过程中可以携带数据吗
第三次握手时可以携带数据，但是第一、二次不行。
原因：设想这样的场景：若第一次握手可以携带数据，有人要恶意攻击服务器，则他每次都可以在第一次握手中的SYN报文中放入大量数据，会让服务器花费很多时间、空间来处理报文。
这就是SYN攻击： Client在短时间伪造大量不存在的ip地址，向Server不断发送SYN包，Server则回复确认包，并等待Client确认，这些包将长时间占用未连接队列，导致正常的SYN请求因为队列满被丢弃，从而引起网络拥塞甚至系统瘫痪（Dos/DDoS攻击）
也就是说：第一次握手无法放数据，保证了服务器的安全性。而第三次握手时，已经代表成功的建立了连接，从客户端携带数据到服务器也是被理解的。
TCP通信（可靠传输的实现）
TCP发送的报文段是交给IP层发送的。但是IP层只能提供尽最大努力服务，也就是说，TCP下面的网路所提供的的是不可靠的传输。因此TCP必须采用适当的措施才能使两个运输层之间的通信变得可靠。
在理想条件下：传输信道不产生差错；不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。
然而实际的网络中都不具备以上的条件。于是使用一些可靠传输协议：
当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度。
可靠的工作原理 ：连续ARQ协议和滑动窗口
自动重传ARQ协议： 重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。
连续ARQ协议：
连续ARQ协议规定，发送方的发送窗口内的分组都可以连续发送出去，而不需要等待对方的确认。发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认。
滑动窗口工作原理：
发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据。在TCP连接阶段，接收方就已经把自己的接受窗口值放在窗口字段中发送给对方了。
接收方对于收到的有序分组，向发送方发送确认信息，对于没有按序到达的分组，先暂存在接受窗口中。
发送方根据收到的确认信息，以及接收方窗口大小，向前移动滑动窗口或者不移动窗口。
如果发送窗口内的分组都已经发送但没有收到确认，发送方会在一段时间过后重传这部分数据。
发送与接收缓存：
发送缓存用来暂时存放：
（1）发送应用程序传送给发送方TCP准备发送的数据
（2）TCP已经发送但尚未收到确认的数据
发送窗口只是发送缓存的一部分。已被确认的数据要从发送缓存中删除。发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存就会没有存放数据的空间。
接收缓存用来暂时存放：
（1）按序到达的、但尚未被接收应用程序读取的数据
（2）未按序到达的数据
如果收到的分组被检测出有差错，则要丢弃。如果接收应用程序来不及读取收到的数据，接收缓存最终会被填满，使接收窗口减小到零。反之，接收窗口就可以增大，但最大不能超过接收缓存的大小。
TCP流量控制
一般来收，希望的是数据传输的更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，就会造成数据的丢失。流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。利用滑动窗口机制可以很方便地在TCP连接上事项发送方的流量控制。
TCP拥塞控制
过多的数据注入到网络中，对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，就会造成拥塞。
例如：路由器过载，路由器没有足够的空间，他就会丢弃一些新到的分组。发送方多次重传还会家中拥塞程度。
TCP的拥塞控制方法：
TCP进行拥塞控制的算法有四种：慢开始、拥塞避免、快重传、快恢复
拥塞控制也叫做基于窗口的拥塞控制。发送方维持一个叫做拥塞窗口的状态量。拥塞窗口的大小取决于网络的拥塞程度，而且在动态地变化。发送方让自己的发送窗口等于拥塞窗口。
发送方控制拥塞窗口的原则是：
只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，来缓解网络拥塞。
发送方又是如何知道网络发生了拥塞呢？
当网络发生拥塞时，路由器就要丢弃分组。因此只要发送方没有按时收到应当到达的确认报文，出现了超时，就可以判断网络出现了拥塞。
拥塞窗口cwnd的大小变化：
1、慢开始算法：刚开始发送数据，由于不清楚网络的负荷能力，所以由小及大逐渐增大发送窗口
（由小到大逐渐增大拥塞窗口数值），每经过一个传输轮次，拥塞窗口就加倍。
为了防止拥塞窗口增长过大引起网络拥塞，还设置里一个慢开始门限ssthresh.
当cwnd<ssthresh，使用慢开始算法。
当cwnd>ssthresh，改用拥塞避免算法。
当cwnd=ssthresh，既可以使用慢开始，也可使用拥塞避免算法。
2、拥塞避免算法：把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。 但不能完全避免拥塞。
3、快重传算法：有时个别报文段会在网络中丢失，但实际网络并没有发生拥塞。快重传规定，发送方只要一连收到三个重复确认，就知道接收方确实没有收到某个缺序的报文段，因而应当立即进行重传。 这样，发送方就不会误认为出现了网络拥塞，增加网络吞吐量。
4、快恢复算法： 当发送方知道只是丢失了个别的报文段，于是不启动慢开始算法，而是执行快恢复算法 （快速恢复拥塞避免算法）
(可以认为快重传和快恢复是同时进行的)
TCP断开（四次挥手）
为什么建立一个连接要三次握手，而终止需要四次呢？这是由TCP的半关闭造成的。即，TCP提供了连接的一段在结束它的发送后还能接收来自另一端数据的能力。
双方均可主动发起挥手
假设客户端先发起关闭请求：
第一次挥手： 客户端发送一个FIN报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。
即：报文段：FIN=1，seq=u。 客户端进入FIN_WAIT1状态。
FIN报文段即使不携带数据，他也消耗掉一个序号。
第二次挥手： 服务器收到FIN后，会发送ACK报文，且把客户端序列号值+1作为ACK报文的序列号值，表示已经收到客户端的报文了，此时服务器处于CLOSE_WAIT状态。
即：报文段：ACK=1，ack=u+1，seq=v。服务器进入CLOSE_WAIT状态。客户端收到服务端的确认后，进入FIN_WAIT2状态，等待 B发送FIN报文。
（这时的TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A任然要接受。也就是说，从B到A这个方向的连接并没有关闭，这个状态会持续一段时间）
第三次挥手： 如果服务器也想断开连接了，发送FIN报文，并且由于这是对于回应报文，因此确认标志ACK仍需置1，服务器端处于LAST_ACK状态
即：报文段：ACK=1，FIN=1，ack=u+1(仍算是对seq=u的回应)，seq=w。，服务器进入LAST_ACK状态。
第四次挥手： 客户端收到FIN后，发送一个ACK作为应答，此时客户端处于TIME_WAIT2状态，而服务端收到ACK报文后，就处于CLOSED状态.
即：报文段：ACK=1，seq=u+1(第一次为seq=u)，ack=w+1。客户端进入TIME_WAIT状态，此时TCP还未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。
断开挥手为什么需要四次
当服务器端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”，只有等我服务端所有的报文都发送完毕， 我才能发送FIN报文。
等待2MSL的意义
MSL译为“最长报文段寿命”，是任何报文在网络上存在的最长时间，超过这个时间，报文将被丢弃。
理由一：保证客户端发送的最后一个ACK报文段能够到达服务端。
若客户端发送的最后一个ACK报文段在传输过程丢失，服务器接受不到回应，会超时重传一次FIN+ACK，而客户端就能在2MSL时间内收到这个重传的FIN+ACK，并且也重传一次确认，重新启动2MSL计时器。最后，双方都正常进入到CLOSED阶段
假设客户端在TIME-WAIT阶段不等待2MSL，而是在发送完ACK后直接释放关闭，一旦这个ACK丢失的话，服务器就无法正常进入关闭连接状态。
理由二：防止“已失效的连接请求报文段”出现在本连接中
A在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段（第一次握手晚到的SYN请求报文段）。
TCP粘包与拆包
参考博客链接: https://zhanglong.blog.csdn.net/article/details/117320585.
什么是TCP粘包？
TCP粘包是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓存区来看，后一包的数据头紧接着前一包的数据尾，出现粘包的原因是多方面的，可能来自发送方，也可能来自接收方。
1、发送方原因：
要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。
TCP默认使用Nagle算法，Nagle算法可能造出现粘包问题。
Nagle算法主要作用：减少网络中报文段的数量。而Nagle算法主要做两件事：
1、只有上一个分组得到确认，才会发送下一个分组
2、收集多个小分组，在一个确认到来时一起发送
2、接收方原因
接收数据端的应用层没有及时读取接收缓存区中的数据，将发生粘包。
什么时候需要处理粘包现象
1、若粘包的多组数据为同一块数据(文件)的不同部分，则无需处理。
2、若多个分组毫无关联，则需要处理粘包现象。
如何处理粘包现象
1、发送方
可以通过关闭Nagle算法解决，使用TCP_NODELAY选项来关闭算法
2、接收方
接收方没有办法处理粘包显现，只能交给应用层处理
3、应用层
应用层解决粘包的方法非常简单，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。
解决方法：循环处理，应用程序从接受缓存中读取分组时，读完一条数据，就应循环读取下一条数据，直到所有数据都被处理完成，但如何判断每条数据的长度呢？
1、格式化数据：每条数据都有固定格式，如开始符，结束符等。
这种方法简单可行，但选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。
2、发送长度：发送每条数据时，数据包中有专门的位置记录该数据的长度，当应用层读取数据包时，就可以根据数据包长度将每个分组进行拆包。
应用层处理粘包的方法叫拆包。
UDP会不会产生粘包问题？
TCP： 为了保证可靠传输并减少额外开销，采用了基于流的传输，流传输不会把消息按个传输，而是无保护消息边界的。
保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息。
UDP： 面向消息传输，有保护消息边界，接收方一次只接受一条独立的消息，因此不存在粘包问题。
应用层
运输层为应用进程提供了端到端的通信服务。但在不同的网络应用的应用进程之间，还需要有不同的通信规则。因此还需要应用层协议来解决不同的应用问题。
域名系统DNS
用户与互联网上某台主机通信时，必须要知道对方的IP地址。然而用户很难记住长达32位的二进制主机地址。用户层为了便于用户记忆各种网络应用，连接在互联网上的主机不仅有IP地址，而且还有便于用户记忆的主机名字。域名系统能够把互联网上的主机名字转换为IP地址。
域名到IP地址的解析过程是由分布在互联网上的许多域名服务器程序共同完成的。
域名到IP地址的解析过程要点如下：当某一个应用进程需要把主机名解析为IP地址时，该应用进程就调用解析程序，并成为DNS的一个用户，把待解析的域名放在DNS请求报文中，以UDP用户数据报方式发给本地域名服务器（使用UDP是为了减少开销）。 本地域名服务器在查找域名后，把对应的IP地址放在回答报文中返回。应用进程获得目的主机的IP地址后即可进行通信。若本地域名服务器不能回答该请求，则此域名服务器就暂时成为DNS中的另一个客户，并向其他域名服务器发出查询请求。
域名解析过程：2种查询方式
迭代查询：特点：本地域名服务器只与根服务器进行相互通信。
递归查询：特点：本地域名服务器要和其他所有有关的服务器都进行直接的两两通信。
具体采用哪一种方式取决于最初的查询请求报文的设置是要求使用哪一种查询方式。
超文本传输协议HTTP
HTTP协议定义了浏览器（即万维网客户进程）怎样向万维网服务器请求万维网文档，以及服务器怎样把文档传送给浏览器。 HTTP不仅传送完成超文本跳转所必须的信息，而且也传送任何可从互联网上得到的信息，如超文本、文本、声音和图像等。
HTTP使用了面向连接的TCP作为运输层协议。但是，HTTP协议本身是无连接的。也就是说，虽然HTTP使用了TCP连接，但通信的双方在交换HTTP报文之前不需要先建立HTTP连接。
HTTP协议首先要和服务器建立TCP连接。这就需要三报文握手。当建立TCP连接的三报文握手的前两部分完成后，万维网客户就把HTTP请求报文，作为建立TCP连接的三报文握手中的第三个报文的数据，发送给万维网服务器（我们知道，在TCP连接的第一二次握手是无法携带数据的，第三次握手是可以携带数据的）。服务器收到HTTP请求报文后，就把所请求的文档作为响应报文返回给客户。
HTTP报文：
由于HTTP是面向文本的，因此在报文中的每一个字段都是一些ASCII码，因而各个字段的长度都是不确定的。
请求报文：
响应报文：
Cookie
由于HTTP是无状态的，即同一个客户第二次访问同一个服务器上的页面时，服务器的响应与第一次被访问时的相同， 因为服务器并不记得曾经访问过的这个客户，也不记得为该客户曾经服务过多少次。HTTP的无状态特性简化了服务器的设计，是服务器更容易支持大量并发的HTTP请求。但在实际工作中，一些万维网站点却常常希望能够识别用户。
例如：在网上购物时，将选好的物品放入购物车，继续浏览和预购其他商品。服务器必须记住用户的身份，才能使商品放在同一个购物车。
要做到记住客户，就可以在HTTP中使用Cookie。Cookie表示在HTTP服务器和客户之间传递的状态信息。
工作原理：
当用户A浏览某个网站时，该网站的服务器就为用户A产生一个唯一的识别码， 然后在后端数据库中产生一个项目。接着在给A的HTTP响应报文中添加一个叫做Set-cookie的首部行，值为赋予该用户的识别码。
当A收到这个响应时，其浏览器就在它管理的特定Cookie文件中添加一行，其中包括这个服务器的主机名和Set-cookie后面给出的识别码。当A继续浏览这个网站时，每发送一个HTTP请求报文，其浏览器就会从其Cookie文件中提取出这个网站的识别码，并放到HTTP请求报文的Cookie首部行中：
于是服务器就可以跟踪这个用户在该网站的活动。
（如果在该网站登记过密码和邮件等信息，只要是在同一个电脑浏览这个网址，就不必重新输入信息）
Cookie只是一个小小的文本文件，不是计算机病毒，不是计算机可执行程序。
Session
参考文章https://www.cnblogs.com/l199616j/p/11195667.html#_label1_0.
Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。
Session与Cookie比较
实现机制： Session的实现常常依赖于Cookie。通过Cookie机制回传SessionID。
大小限制： Cookie有大小限制，并且浏览器对每个站点也有个数限制，session无大小限制，理论上只与服务器的内存大小有关。
安全性： Cookie存在安全隐患，通过拦截或本地文件找到cookie后可以进行攻击，而session由于保存在服务器端，相对更安全。
服务器资源消耗： Session保存在服务器端过一段时间才会消失，若session过多会增加服务器压力。
网络安全
参考文章：https://zhanglong.blog.csdn.net/article/details/117320585.
公钥和私钥
公钥和私钥是通过一种算法得到的一个密钥对，公钥是秘钥对中公开的部分，私钥是非公开的部分。如果用其中一个密钥加密一段数据，必须用另一个密钥解密。比如用公钥加密数据就必须用私钥解密，如果用私钥加密也必须用公钥解密，否则解密将不会成功。
原则：公钥公开，私钥只有自己拥有。
对称加密与非对称加密
对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；
非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。
总结一下：通过非对称加密的方式把秘钥发送过去，接下来用这个秘钥一直进行对称加密。
即：第一次通信采用非对称加密，接下来的通信采用对称加密
RSA加密算法
参考文章： https://www.cnblogs.com/soldierback/p/11601824.html.
RSA算法是一种非对称的加密算法，它通常是先生成一对RSA密钥，其中之一是保密密钥（私钥），由用户保存；另一个为公开密钥（公钥），可对外公开；要加密传输内容时，比如A要给B传输信息，此时A先用B的公钥将内容加密后传输，B收到A传输过来的信息后用自己的私钥解密.
该过程中，只要B不泄露自己的私钥，那么就算第三方截取到了该信息，没有B的私钥也无法解密获得内容信息.
RSA算法的安全性依赖于大数分解，计算两个大素数的乘积很容易，但是反过来由该乘积分解成两个素数相乘，如果该乘积够大的话，分解的难度是极其大的
HTTPS
当万维网能够提供网上购物时，安全问题就来了。客户要确保服务器属于真正的销售商、客户与服务器要确保诸如信用卡号之类的敏感信息不会被冒充者窃听等等问题。
像这些安全服务，需要使用运输层的安全协议。其中一个就是SSL（安全套接字层）
SSL
SSL作用在端系统应用层的HTTP和运输层之间，在TCP之上建立起一个安全通道，为通过TCP传输的应用层数据提供保障。
应用层使用SSL最多的就是HTTP。
当使用普通不加密的浏览器查看网页时，HTTP就直接使用TCP连接，这时SSL不起作用。但使用信用开进行网上支付，要键入信用卡密码时，就需要使用安全浏览器。这时应用程序HTTP就调用SSL对整个网页进行加密。网址栏中，http变成了https，s代表security，表明现在使用的是提供安全服务的HTTP协议。
发送方：SSL从SSL套接字接收应用层数据，对数据加密，然后把加密的数据送往TCP套接字；
接收方： SSL从TCP套接字读取数据，解密后，通过SSL套接字把数据交给应用层。
工作流程：
HTTPS为什么安全
1、混合加密
作用：防窃听
混合加密：即同时采用公钥和私钥加密，更安全，更高效，更不易被破解。
HTTPS采用对称加密和非对称加密结合的混合加密方式
在通信建立前采用非对称加密的方式交换秘钥，后续就不在使用非对称加密。
在通信过程中全部使用对称加密的会话秘钥方式，加密明文数据。
2.、摘要算法
作用：防止数据被篡改。
摘要算法：实现数据完整性，能够为数据生成独一无二的指纹，指纹用于校验数据的完整性，解决了被篡改的风险。
过程
1、客户端发送明文前，会通过摘要算法算出明文的指纹，发送时明文和指纹一同加密，发送给服务器。
2、服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的指纹和当前指纹做比较，若相同，则说明数据是完整的。
3.、数字证书
作用：解决身份认证问题。
过程：借助第三方权威机构CA（数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构办法）中，只要证书是可信的，公钥就是可信的。
HTTP与HTTPS区别
端口不同： HTTP与HTTPS使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
资源消耗： 和HTTP通信相比，HTTPS通信会由于加减密处理消耗更多的CPU和内存资源；
开销： HTTPS通信需要证书，而证书一般需要向认证机构购买；
以上是关于计算机网络面经——计算机网络详细知识点的主要内容，如果未能解决你的问题，请参考以下文章