计算机网络面试题整理

1. OSI、TCP/IP、五层协议的体系结构?

OSI分层(七层):物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。

TCP/IP(4层):网络接口层、网际层、运输车、应用层。

五层协议(5层):物理层、数据链路层、网络层、运输层、应用层。

每一层的作用如下:

物理层:激活、维持、关闭通信短点之间的机械特性、电气特性、功能特性以及工程特性。该层为上层协议提供了一个传输数据的物理媒体。

数据链路层:数据链路层在不可靠的物理介质上提供可靠的传输。改层的作用包括:物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。

网络层:网络层负责对子网间的数据包进行路由选择。此外,网络层还可以实现拥塞控制、网际互连等功能。

传输层:第一个端到端,即主机到主机的层次。传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外,传输层还要处理端到端的差错控制和流量控制问题。

会话层:会话层管理主机之间的回话进程,即负责建立、管理、终止进程间的会话。会话层还利用在数据中插入校验点来实现数据的同步。

表示层:表示层对上层数据或信息进行变换以保证一个主机应用层信息可以被另一个主机应用程序理解。表示层的数据转换包括数据的加密、压缩、格式转换等。

应用层:为操作系统或网络应用程序提供访问网络服务的接口。
在这里插入图片描述

2. IP地址的分类

所谓的“分类的IP地址”就是将IP地址划分为若干个固定类,每一类地址都是由两个固定长度的字段组成,其中一个字段是网络号(net-id),它标志主机(或路由器)所连接到的网络。一个网络号在整个因特网范围内必须是唯一的。第二个字段时主机号(host-id),它标志该主机(或路由器)。一个主机号在它前面的网络号所指明的网络范围内必须是唯一的。由此可见,一个IP地址在整个英特网范围内是唯一的。

IP地址可以分为A类、B类、C类、D类和E类地址。

A类地址:以0开头,第一个字节作为网络号,地址范围为:0.0.0.0 ~ 127.255.255.255。

B类地址:以10开头,前两个字节作为网络号,地址范围为:128.0.0.0 ~ 191.255.255.255.

C类地址:以110开头:前三个字节作为网络号,地址范围为:192.0.0.0 ~ 223.255.255.255。

D类地址:以1110开头,地址范围为:224.0.0.0 ~ 239.255.255.255,D类地址作为组播地址(即一对多通信)。

E类地址:以1111开头,地址范围为:240.0.0.0 ~ 255.255.255.255,E类地址为保留地址,供以后使用。

需要注意的是:只有A、B、C类地址有网络号和主机号之分,D和E类地址没有划分网络号和主机号。

3. TCP与UDP的区别?

  • TCP是面向连接的(如打电话需要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接。
  • TCP提供可靠的服务,也就是说通过TCP连接传送的数据无差错、不重复、且按序到达;而UDP不保证数据传输的可靠性。
  • TCP是面向字节流的,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的。UDP没有拥塞控制,因此网络出现拥塞不会使得源主机的发送速率降低(对实时应用很有用,如IP电话、实时视频会议等)。
  • 每一条TCP连接只能是点对点的;而UDP支持一对一、一对多、多对一、多对多的交互通信。

4. TCP如何实现数据的可靠性?

TCP通过校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制等机制来保证可靠性。

4.1 校验和

在数据传输过程中,将发送的数据段都当做一个16位的整数。将这些整数加起来,并且前面的进位不能丢弃,补在最后,然后取反,得到校验和。

  • 发送方:在发送数据之前计算校验和,并进行校验和的填充。

  • 接收方:收到数据后,对数据以同样的方式进行计算,求出校验和,与发送方进行比较。
    在这里插入图片描述

4.2. 序列号

TCP传输时将每个字节的数据都进行了编号,这就是序列号。序列号的作用不仅仅是应答作用,有了序列号能够将接收到的数据根据序列号进行排序,并且去掉重复的数据。这也是TCP可靠性的保证之一。

4.3. 确认应答

TCP传输过程中,每次接收方接收到数据后,都会对传输方进行确认应答。也就是发送ACK报文,这个ACK报文中带有对应的确认序列号,告诉发送方,接收了哪些数据,下一次数据从哪里传。

4.4 超时重传

在进行TCP传输时,由于存在确认应答与序列号机制,也就是说发送方发送一部分数据后,都会等待接收方发送的ACK报文,并解析ACK报文,判断数据是否传输成功。如果发送方发送完数据后,迟迟都没有接收到接收方传来的ACK报文,那么就对刚刚发送的数据进行重发,如果是数据在传输过程中用于网络原因等发生丢包,导致接收方没有接收到,那么接收方第二次收到了数据后就会发送ACK报文给发送方;如果是接收方已经发送了ACK报文,但是ACK报文由于网络原因丢包了,导致发送方没有收到ACK报文,那么此时发送过来的报文已经存在就直接丢弃,仍然发送ACK报文。

4.5 连接管理

就是三次握手、四次挥手的过程。

4.6 流量控制

接收端在接收到数据后,对其进行处理。如果发送方的发送速度太快,导致接收方的接收缓冲区填充满了。此时如果继续传输数据,就会造成大量丢包,继而引起丢包重传等等一系列问题。因此TCP支持根据接收端的处理能力,来决定发送端的发送速度,这就睡流量控制机制。接收端可以将自己的接收缓冲区大小放入TCP首部的“窗口大小”字段中,通过ACK通知发送端。以此来决定发送端的发送速度。如果接收缓冲区满了,窗口设置为0,这时发送方将不会再发送数据,但是会定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端。

4.7 拥塞控制

TCP传输过程中,发送端开始发送数据的时候,如果一开始就发送大量数据,那么就有可能造成一些问题。如:网络可能在刚开始的时候就很拥堵,如果给网络中再扔出大量数据,那么这个拥堵就会加剧。拥堵的加剧会导致大量丢包,就会产生大量的超时重传,严重影响传输效率。

所以TCP引入了慢启动机制,在开始发送数据的时候,先发少量的数据探探路。探清楚当前的网络状况如何,再决定按照多大的速度传输数据。这里需要引入一个拥塞窗口,发送开始的时候,拥塞窗口大小为1,每次接收到一个ACK应答,拥塞窗口加1,每次发送数据包的时候,将拥塞窗口和接收端的主机反馈的窗口大小做比较,取较小的值作为作为实际发送的窗口。

虽然“慢启动” 初始值很小,但是增长速度非常快,是指数级别的。因此在这里引入了一个慢启动阈值,当拥塞窗口超过这个阈值的时候,不再按照指数的方式增长了,而是线性增长。当TCP 开始启动的时候,慢启动的阈值等于窗口的最大值,在每次超时重发的时候,慢启动阈值会变成原来的一半,同时拥塞窗口会置为1。
在这里插入图片描述

5. TCP协议如何提高传输效率?

TCP协议提高效率的方式有滑动窗口、快重传、延迟应答、捎带应答等。

5.1. 滑动窗口

如果每一个发送的数据段,都要给一个ACK应答之后再发送下一个数据段,这样的话我们效率很低,大部分时间都用在了等待ACK应答上了。

既然如此,那么我们可以一次发送多条数据,这样就能使等待时间大大减少,从而提高性能。
在这里插入图片描述
窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节(四段数据)。

发送前四个段的时候,不需要等待任何ACK,直接发送;

收到第一个ACK后,滑动窗口向后移动,继续发送第五个段的数据,依次类推;

操作系统内核为了维护这个滑动窗口,需要开辟发送缓冲区来记录当前还有哪些数据没有应答;只有确认应答过的数据,才能从缓冲区删掉;

窗口越大,则网络吞吐量越大。
在这里插入图片描述

5.2. 那么如果出现了丢包,如何进行重传?这里分两种情况。

情况一:数据包已经抵达,ACK被丢了。
在这里插入图片描述
这种情况下,部分ACK丢了并不影响,因为可以通过后续的ACK进行确认;

情况二:数据包直接丢了。
在这里插入图片描述
当某一段报文段丢失后,发送端会一直收到1001这样的ACK,就像是在提醒发送端“我想要的是1001”一样;

如果发送端主机连续三次收到了同样一个“1001”这样的应答,就会将对应的数据段 1001~2000 重新发送;

这个时候接收端接收到了1001之后,再返回的ACK就是7001了,因为2001~7000这段数据接收端之前就已经收到了,被放到了接收端操作系统内核的接收缓冲区。

这种机制就叫做“高速重发控制”(也称“快重传”)。

5.3. 延迟应答

如果接收数据的主机立刻返回ACK应答,这时候返回的窗口大小可能比较小。

  • 假设接收端缓冲区为1M,一次收到了512K的数据;如果立刻应答,返回的窗口就是512K;
  • 但实际上可能处理端处理速度很快,10ms之内就把512K的数据从缓存区消费掉了;
  • 在这种情况下,接收端处理还远没有达到自己的极限,即使窗口再放大一些,也能处理过来;
  • 如果接收端稍微等一会在应答,比如等待200ms再应答,那么这个时候返回的窗口大小就是1M;

窗口越大,网络吞吐量就越大,传输效率就越高;我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。

5.4. 捎带应答

在延迟应答的基础上,很多情况下,客户端服务器在应用层也是一发一收的。这时候常常采用捎带应答的方式来提高效率,而ACK响应常常伴随着数据报文共同传输。如:三次握手。

6. 三次握手

  • 建立连接时,客户端向服务端发送请求报文段,这时首部中的同步位SYN=1,同时选择一个初始序号seq=x,这时客户端进入SYN_SENT(同步已发送)状态。

  • 服务端收到连接请求报文段后,如果同意建立连接,则向客户端发送确认报文。在确认报文中把SYN位和ACK位都置为1,确认号是ack=x+1,同时也为自己选择一个初始序号seq=y。这时服务器进入SYN_RECV(同步收到)状态。

  • 客户端接收到服务器发来的确认报文后,还要向服务端发送确认报文,确认报文段的ACK置为1,确认序号ack=y+1,而自己的序号置为seq=x+1,报文发送完毕后,客户端进入ETABLISHED(已连接)状态;当服务端收到客户端的确认报文后也进入ETABLISHED状态。

为什么是三次?(⭐⭐)

  • 两次不安全,有可能SYN会延迟,缺乏状态保护的情况下,收到一个SYN就会建立一个新的socket,完整的状态保护避免对一个客户端创建多个socket
    ;有了三次握手,在收到第一个SYN后,此时服务端就等待客户端的ACK回复确认,这期间就算收到了客户端的新的SYN也不会理睬,就不会创建新的socket;

  • 两次不安全,服务端无法通过客户端的SYN确定客户端具有数据收发能力,需要再次进行确认;

  • 为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误

7、四次挥手

  • 客户端先向服务端发出连接释放报文段,用来关闭客户端到服务端的数据传送,这时首部中的FIN置为1,其序号为u。这时客户端进入FIN_WAIT_1(终止等待1)状态,等待服务端的确认。

  • 服务端收到客户端的连接释放报文段后即发出确认,确认号为ack=u+1,序号为v。这时服务端进入CLOSE_WAIT(关闭等待)状态。此时客户端到服务端这个方向的连接就释放了,这时客户端与服务器的连接处于半关闭状态。客户端收到服务端的确认报文后,就进入了FIN_WAIT_2(终止等待2)状态,等待服务端发出的连接释放报文段。

  • 服务端向客户端发送连接释放报文段,用来关闭服务端到客户端的数据传送,这时首部中的FIN置为1,序号为w,此时服务端进入LAST_ACK(最后确认)状态,等待客户端的确认。

  • 客户端收到服务端的连接释放报文段后,必须对此发出确认。在确认报文中把ACK置为1,确认号ack=w+1。此时客户端进入TIME_WAIT(时间等待)状态。此时TCP连接还没有释放,需经过等待计时器设置的2MSL(MSL:Maximum Segment Lifetime 最大报文生存时间,MSL是任何报文段被丢弃前在网络内的最长时间)后,才进入到CLOSE状态。到此才算完成了整个四次挥手的过程。

挥手为什么四次?(⭐⭐)

被动关闭方,收到FIN之后对其进行ACK回复,但是不能直接关闭socket,因为这时候用户有可能正在处理数据(socket接受缓冲区中有可能还有堆积的数据),需要用户来确认什么时候关闭socket发送FIN;因此ACK和FIN不能放在一起;

为什么建立连接是三次握手,而关闭连接却是四次挥手呢?(⭐⭐)

这是因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。而关闭连接时,当收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,己方也未必全部数据都发送给对方了,所以己方可以立即close,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送。

8.在浏览器中输入一个www.baidu.com后执行的全部过程?

域名解析 -> 建立TCP连接(三次握手)-> 发起http请求 -> 服务器响应http请求,浏览器得到html代码 -> 浏览器解析html代码,并请求html代码中的资源(如 js、css、图片等)-> 浏览器对页面进行渲染呈献给用户
在这里插入图片描述

8.1 域名解析

8.1 域名解析

  • 浏览器会首先搜索浏览器的DNS缓存,看自身的缓存中是否有www.baidu.com对应的条目,而且没有过期,如果有且没有过期则解析到此结束。

  • 如果浏览器自身的缓存中没有找到对应的条目,那么浏览器会搜索操作系统的DNS缓存,如果找到且没有过期则停止搜索解析到此结束。(在Windows系统的命令行下使用 ipconfig/displaydns 进行查看)

  • 如果 Windows 系统的 DNS 缓存也没有找到,那么就尝试读取 hosts文件(位于C:\Windows\System32\drivers\etc),查看这里面有没有该域名对应的 IP 地址,如果有则解析成功。

  • 如果在 hosts文件中也没有找到对应的条目,浏览器会先向本地DNS服务器发起域名解析请求(通过的是UDP协议向DNS的53端口发起请求,这个请求是递归的请求),本地的DNS服务器一般来说都是由网络接入商提供的,如中国电信等。当本地的DNS服务器收到请求后,服务器会先查询自己的缓存,找到对应的条目,且没有过期,则解析成功。如果没有找到,本地的DNS服务器就向根DNS服务器发起请求进行查询。根DNS服务器上是没有记录哪个域名和IP的对应关系的,他会告诉本地的DNS服务器可以到某个域服务器上进行查询,并且告诉它这个域服务器的地址,这个过程是迭代查询的。以www.baidu.com为例,根DNS服务器发现这是一个顶级域com域的一个域名,就会将这个顶级域com域的IP地址告诉本地DNS服务器。这时候本地的DNS服务器会向该域服务器发起请求,当com域服务器接收到请求后并不会直接返回这个域名对应的IP地址,而是告诉本地DNS服务器该域名对应的DNS地址(这个一般是由域名注册商提供的);于是本地DNS服务器就会向www.baidu.com这个域名的DNS地址发起请求,这时候本地的DNS服务器才能拿到这个域名对应的IP地址,并返回给操作系统内核,内核又把结果返回给浏览器,至此浏览器才拿到www.baidu.com这个域名对应的IP地址,就能进行下一步了。

  • 在这里插入图片描述

8.2 建立TCP连接

拿到域名对应的IP地址之后,User-Agent(一般是指浏览器)会以一个随机端口(1024 < 端口 < 65535)向服务器的WEB程序(常见的有tomcat、nginx等)80端口发起TCP的连接请求。这个连接请求(原始的http请求经过TCP/IP4层模型的层层封包)到达服务器端后(这中间通过各种路由设备,局域网内除外),进入到网卡,然后是进入到内核的TCP/IP协议栈(用于识别该连接请求,解封包,一层一层的剥开),还有可能要经过Netfilter防火墙(属于内核的模块)的过滤,最终到达WEB程序,最终建立了TCP/IP的连接。

8.3 发起http请求

HTTP请求报文的方法是get方式,如果浏览器存储了该域名下的Cookies,那么会把Cookies放入HTTP请求头里发给服务器。

8.4 服务器响应http请求,浏览器得到html代码

服务器端WEB程序接收到http请求以后,就开始处理该请求,处理之后就返回给浏览器html文件。

8.5 浏览器解析html代码,并请求html代码中的资源

浏览器拿到index.html文件后,就开始解析其中的html代码,遇到js/css/image等静态资源时,就向服务器端去请求下载(会使用多线程下载,每个浏览器的线程数不一样),这个时候就用上keep-alive特性了,建立一次HTTP连接,可以请求多个资源,下载资源的顺序就是按照代码里的顺序,但是由于每个资源大小不一样,而浏览器又多线程请求请求资源,所以从下图看出,这里显示的顺序并不一定是代码里面的顺序。

浏览器在请求静态资源时(在未过期的情况下),向服务器端发起一个http请求(询问自从上一次修改时间到现在有没有对资源进行修改),如果服务器端返回304状态码(告诉浏览器服务器端没有修改),那么浏览器会直接读取本地的该资源的缓存文件。

8.6 浏览器对页面进行渲染呈献给用户

最后,浏览器利用自己内部的工作机制,把请求到的静态资源和html代码进行渲染,渲染之后呈现给用户。

9. HTTP协议

HTTP是基于TCP/IP协议的应用程序协议,不包括数据包的传输,主要规定了客户端和服务器的通信格式,默认使用80端口。

9.1 HTTP报文

请求报文
在这里插入图片描述
响应报文

在这里插入图片描述
请求头和响应头的部分字段含义:

  • Host:指定服务器域名,可用来区分访问一个服务器上的不同服务。
  • Connection:keep-alive表示要求服务器不要关闭TCP连接,close表示明确要求关闭连接,默认值是keep-alive。
  • Accept-Encoding:说明自己可以接收的压缩方式。
  • User-Agent:用户代理,是服务器能识别客户端的操作系统(Android、IOS、WEB)及相关信息。作用是帮助服务器区分客户端,并且针对不同客户端让用户看到不同数据,做不同操作。
  • Content-Type:服务器告诉客户端数据的格式,常见值有text/plain、image/jpeg、image/png、video/mp4、application/json、application/zip。这些数据类型总称为MIMETYPE。
  • Content-Encoding:服务器数据压缩方式。
  • Transfer-Encoding:chunked表示采用分块传输编码,有该字段则无需使用Content-Length字段。
  • Content-Length:声明数据的长度,请求和回应头部都可以使用该字段。

9.2 HTTP方法

在这里插入图片描述

9.3 HTTP状态码(⭐)

在这里插入图片描述

9.4 POST方法和GET方法的区别(⭐)

  1. GET和POST方法其实没有本质区别,只是报文格式不同
    GET和POST只是HTTP协议中两种请求方式,而HTTP协议又是基于TCP的应用层协议,它们都是用的同一个传输层协议,所以在传输上,并没有区别;

  2. 在报文格式上不带参数时,HTTP请求首行不同而已
    带参数时:GET方法的参数应该放在URL中,POST方法参数放在请求体中
    (因为两种方法本质都是TCP连接,所以你也可以在使用GET方法时,把参数放在请求体,或者在使用POST方法时,把参数放在URL中,但这需要服务端的支持,也就是说,服务端在读取的时候设置好了一定的格式,按照指定来的)

  3. 缓存(Cache):GET方法提交能被缓存,而POST不能被缓存,这也意味着GET提交的参数能被保留在浏览器历史,而POST不能

  4. 安全性:与POST相比,GET的安全性较差,因为所发送的数据是URL的一部分,在地址栏上就可见;相对而言,POST方式更加安全,因为参数不会被保存在浏览器历史或web服务器日志中
    但真正的安全性来讲:GET和POST都是不安全的,因为HTTP在网络上传输是明文的,上面讲了,数据信息一个在URL中,一个在请求体中,这样我们直接利用抓包工具就可轻而易举的得到HTTP的报文信息,在HTTP的请求信息中,就包含了URL和请求体,这样数据就暴露了;要想安全传输,就得加密,也就是用到HTTPS;

  5. 对数据长度的限制:GET提交时把数据放在URL中,而URL长度受到一定的限制;而POST把数据放在请求体中,对数据长度没有限制(所以传输较大数据用POST请求方法);
    但在HTTP协议的标准文档中,并没有对URL的长度给与限制,对URL长度的限制是来源于浏览器和服务器,服务器对URL的限制考虑于处理较长的URL要消耗较多的资源,为了性能和安全(防止恶意构造较常URL);

  6. 对数据类型的限制:由于GET方式的数据放在URL中,所以只允许ASCLII字符;而POST方式对数据没有限制,数据存放在请求体中,在POST提交中,请求头Content-Type指定请求体的类型,例如文本格式还是HTML格式等等,这样服务端在读取的时候,用请求头Content-Type来进行解析

10. HTTP与HTTPS的区别

HTTPS=HTTP + 通信加密 + 证书 +完整性保护。

HTTP 与 HTTPS 相比具有以上缺点:明文传输(未加密),不能确定对方身份,没有校验完整性。
而 HTTPS (Secerty) 是将 HTTP 的部分接口用 SSL (Secerty Socket Layer 安全套接字) + TLS (Transmit Layer Secrety 安全传输协议) 代替,原先 HTTP 在应用层,是直接与传输层的 TCP 协议交互,而 HTTPS 是先建立 SSL 连接,再由 SSL 和TCP 通信 。
在这里插入图片描述

10.1 对称 / 共享密钥加密

加密与解密使用相同的密钥。

10.2 非对称 / 公开密钥加密

发送方使用接收方的公钥【随意发布,大家都可见】对数据进行加密发送,而接收方持有私钥【仅自己可见】进行解密。 公钥与私钥是配对儿进行加密、解密的。
公开加密耗时、耗资源,但是可以规避被抓包而密钥被攻击者窃取的问题——因为私钥是不会随数据传输的;而共享加密虽然快,但是传输数据时需要附带着密钥,如果被窃取,就起不到加密的作用了。综合以上,SSL 采用的是混合加密机制——先用 非对称加密,安全地交换密钥,如下图所示,A 获得了 B 发来的 由A公钥加密的🔑 ,并通过 A私钥解密,得到了🔑;同理,B 也获得了 A发来的 由B 公钥加密的 🔑,并通过 B私钥解密,得到了 🔑,他俩得到的是同一把 密钥 🔑,那么以后就可以采用共享加密【 加密、解密用的是相同的密钥 】快速传输数据了,因为A B已经得到钥匙,后续传输数据的过程自然也就不需要再携带密钥了,就不存在被窃取风险。
在这里插入图片描述

10.3 证书

以上过程,客户端与服务器通信时,无法保证对方正是自己想要通信的服务器,需要身份认证。
服务器运营商会向 数字证书认证机构 CA 登录自己的公钥信息,CA 验证后会进行数字签名并授予证书,证书将和服务器的公钥绑定在一起。CA 的公钥是植入到浏览器中的,客户先向 CA 请求,CA 会将证书发送给客户,客户端也就知道了对方服务器的身份、是正规营业商。
而有不正规的 数字证书认证机构,会 “自认证”,这是不符合规范的。

10.4 总结:

  • HTTP协议为超文本传输协议,信息为明文传输;HTTPS为超文本传输安全协议 ,它是具有安全性的SSL(安全套接层)加密传输协议
  • HTTP和HTTPS使用完全不同的连接方式;客户端在发起HTTP连接时默认会连接服务器的TCP80端口,而发起HTTPS访问时连接服务器的TCP443端口
  • https协议需要到CA(证书授权中心)申请证书,因为在进行SSL连接时客户端需要得到服务端的CA证书(里面包含着服务端的公钥,后面需要它来加密);
  • HTTPS就是在HTTP和TCP之间多了一层SSL协议,这层协议专门用来进行加密操作,提供安全保障;
  • 状态不同:HTTP的连接很简单,是无状态的。而HTTPS协议是SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比HTTP协议安全;

11.Cookie和Session的区别

  • Cookie 是在客户端,用来存储状态信息的,是字符串形式,关闭浏览器后直到存活期限结束才会消失。

  • Session是在服务器端,一种用来存放用户数据的 类 Hashtable 结构。可以是任意形式。关闭浏览器就消失

    当客户端第一次访问服务器时,服务器响应请求时会附带 Cookie 做响应,Cookie 中的信息有:name用户名、过期期限等,还有 Session ID ,然后客户端就会把 Cookie 存到本地,之后每次请求都会携带Cookie。

    服务器中,为每个客户端划分个区域,是类 HashMap的,key值是 sessionID ,每次客户端发来请求,服务器会提取 Cookie,然后获取 sessionID ,将客户端对应的区域中获取资源。

示意图如下:
在这里插入图片描述
在这里插入图片描述

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值