计算机网络面试题总结《持续更新》

CSDN什么时候能出个html或者笔记的导入功能?这格式全都没了

1.OSI7层概念模型:

      应用层:主要协议:Http、Https、DNS
      表示层:信息的语法语义以及他们的关联,如加密解密,转换翻译,压缩解压等.
      会话层:不同机器上的用户之间建立以及管理会话,建立和管理应用程序间的通信,主要协议:SSL、RPC
      传输层:接收会话层的数据,在必要时把数据进行分割,并将这些数据交给网络层,并保证这些数据段有效的到达目的地,此层运行的协议如TCP、UDP、WebSorcket协议。
      网络层:控制子网的运行,如逻辑编织,分组传输,路由选择,可能由路由器实现,主要协议:IP协议
      数据链路层:物理寻址,同时将原始byte流转变为逻辑传输线路,可能由交换机实现,主要协议:ARP,MVC
      物理层:机械、电子、定时接口通信信道上的原始比特流传输,例如模数转换
7层模型下的数据发收流程:
计算机网络面试题总结《持续更新》_第1张图片
OSI概念模型的具体实现:TCP/IP四层模型
计算机网络面试题总结《持续更新》_第2张图片
四层模型下的数据发收流程:
计算机网络面试题总结《持续更新》_第3张图片
OSI七层、TCP/IP四层、TCP/IP五层关系如下:
计算机网络面试题总结《持续更新》_第4张图片

2.TCP和UDP协议的定义、特点以及区别:

      TCP定义:TCP 提供面向连接的服务。在传送数据之前必须先建立连接,数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的,面向连接的运输服务(TCP的可靠体现在TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认ACK、滑动窗口、确认重传机制、拥塞控制机制,在数据传完后,还会断开连接用来节约系统资源),这难以避免增加了许多开销,如确认,流量控制,计时器以及连接管理等。这不仅使协议数据单元的首部增大很多,还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。
TCP协议的特点
TCP 是面向连接的。(就好像打电话一样,通话前需要先拨号建立连接,通话结束后要挂机释放连接);
每一条 TCP 连接只能有两个端点,每一条TCP连接只能是点对点的(一对一);
TCP 提供可靠交付的服务。通过TCP连接传送的数据,无差错、不丢失、不重复、并且按序到达;
TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存,用来临时存放双方通信的数据;
面向字节流。TCP 中的“流”(Stream)指的是流入进程或从进程流出的字节序列。“面向字节流”的含义是:虽然应用程序和 TCP 的交互是一次一个数据块(大小不等),但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。
UDP定义:UDP 在传送数据之前不需要先建立连接,远程主机在收到 UDP 报文后,不需要给出任何确认。虽然 UDP 不提供可靠交付,但在某些情况下 UDP 确是一种最有效的工作方式(一般用于即时通信),比如: QQ 语音、 QQ 视频 、直播等等。
UDP协议的特点
UDP 是无连接的;
UDP 使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的链接状态(这里面有许多参数);
UDP 是面向报文的;
UDP 没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如 直播,实时视频会议等);
UDP 支持一对一、一对多、多对一和多对多的交互通信;
UDP 的首部开销小,只有8个字节,比TCP的20个字节的首部要短。
TCP和UDP的区别:
计算机网络面试题总结《持续更新》_第5张图片

3.TCP的三次握手和四次挥手?

计算机网络面试题总结《持续更新》_第6张图片
TCP 三次握手 - 建立一个连接:

我们先了解下TCP报文首部
源端口和目的端口,各占2个字节,分别写入源端口和目的端口;
序号(seq),占4个字节,TCP连接中传送的字节流中的每个字节都按顺序编号。例如,一段报文的序号字段值是 301 ,而携带的数据共有100字段,显然下一个报文段(如果还有的话)的数据序号应该从401开始,表示此次传输的开始的数据包的序号。
确认号(ack),占4个字节,是期望收到对方下一个报文的第一个数据字节的序号。例如,B收到了A发送过来的报文,其序列号字段是501,而数据长度是200字节,这表明B正确的收到了A发送的到序号700为止的数据。因此,B期望收到A的下一个数据序号是701,于是B在发送给A的确认报文段中把确认号置为701;
**发送报文的ack的值一般为上次接收报文的seq的值+1,因为ack表示期望收到的数据的序号,seq表示发送数据的第一个字节的编号。
数据偏移,占4位,它指出TCP报文的数据距离TCP报文段的起始处有多远;
保留,占6位,保留今后使用,但目前应都位0;
紧急URG,当URG=1,表明紧急指针字段有效。告诉系统此报文段中有紧急数据;
**确认ACK,**仅当ACK=1时,确认号字段才有效。TCP规定,在连接建立后所有报文的传输都必须把ACK置1;
推送PSH,当两个应用进程进行交互式通信时,有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应,这时候就将PSH=1;
复位RST,当RST=1,表明TCP连接中出现严重差错,必须释放连接,然后再重新建立连接;
同步SYN,在连接建立时用来同步序号。当SYN=1,ACK=0,表明是连接请求报文,若同意连接,则响应报文中应该使SYN=1,ACK=1;
终止FIN,用来释放连接。当FIN=1,表明此报文的发送方的数据已经发送完毕,并且要求释放;
窗口,占2字节,指的是通知接收方,发送本报文你需要有多大的空间来接受;
检验和,占2字节,校验首部和数据这两部分;
紧急指针,占2字节,指出本报文段中的紧急数据的字节数;
选项,长度可变,定义一些其他的可选的参数。

计算机网络面试题总结《持续更新》_第7张图片
客户端–发送带有 SYN 标志的数据包给服务端 - 一次握手,告诉客户端SYN=1,ACK=0,表示发起连接,从客户端x字节开始传输数据,第一次连接时请求包中只有一个字节,所以下次应从x+1开始传。
服务端–发送带有 SYN/ACK 标志的数据包给客户端 – 二次握手,告诉服务器端,SYN=1,ACK=1表示同意连接(半连接状态),ACK=1,ack置有效,ack=x+1表示服务器端期望客户端从客户端数据的x+1位置开始传输。seq=y表示此数据段从服务器端y位置开始传输数据,此次发送也仅仅只是一个字节,所以下次会从y+1开始传;、
客户端–发送带有带有 ACK 标志的数据包给服务端 – 三次握手,ACK=1,置ack有效(在连接过程中ACK应一直为1),seq=x+1,表示客户端从x+1位置开始传输数据,ack=y+1,表示希望收到服务器端从y+1位置开始传输的数据。

什么是半连接队列?

服务器第一次收到客户端的 SYN 之后,就会处于 SYN_RCVD 状态,此时双方还没有完全建立其连接,服务器会把此种状态下请求连接放在一个队列里,我们把这种队列称之为半连接队列。

当然还有一个全连接队列,就是已经完成三次握手,建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
这里在补充一点关于SYN-ACK 重传次数的问题:
服务器发送完SYN-ACK包,如未收到客户确认包,服务器进行首次重传,等待一段时间仍未收到客户确认包,进行第二次重传。如果重传次数超过系统规定的最大重传次数,系统将该连接信息从半连接队列中删除。
注意,每次重传等待的时间不一定相同,一般会是指数增长,例如间隔时间为 1s,2s,4s,8s…

什么是SYN攻击 ?- 典型的DDOS攻击之一
攻击原理:在三次握手中,Server发送SYN-ACK后,收到Client的ACK之前的TCP连接称为半连接(half-open connect),此时Server处于SYN_RCVD状态,当收到ACK后,Server转入ESTABLISHED状态。

SYN攻击就是Client在短时间内伪造大量不存在的IP地址,并向Server不断地发送SYN包,Server回复确认包,并等待Client的确认,由于源地址是不存在的,因此,Server需要不断重发直至超时,这些伪造的SYN包将长时间占用半连接队列,导致正常的SYN请求因为队列满而被丢弃,从而引起网络堵塞甚至系统瘫痪。
简单来说就是伪造大量客户端发起第一次握手,不发起第三次握手,导致服务器端的半连接队列堵塞。

检测SYN攻击的方式非常简单,即当Server上有大量半连接状态且源IP地址是随机的,则可以断定遭到SYN攻击了,使用如下命令可以让之现行:netstat -nap | grep SYN_RECV

ISN(Initial Sequence Number)初始化序列号是固定的吗?
ISN随时间而变化,因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器,每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送,而导致某个连接的一方对它做错误的解释。
三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number),以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的,攻击者很容易猜出后续的确认号,因此 ISN 是动态生成的。

三次握手过程中可以携带数据吗?
第一次、第二次握手不可以携带数据.第三次握手的时候,是可以携带数据的。
因为第一次握手可以携带数据的话,如果有人要恶意攻击服务器,那他重复在第一次握手中的 SYN 报文中放入大量的数据,这会让服务器花费很多时间、内存空间来接收这些报文。
简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话,此时客户端已经处于 ESTABLISHED 状态。对于客户端来说已经建立起连接了,并且也已经知道服务器的接收、发送能力是正常,能携带数据也没啥毛病

为什么要三次握手?
三次握手的目的是建立可靠的通信信道,说到通讯,简单来说就是数据的发送与接收,而三次握手最主要的目的就是双方确认自己与对方的发送与接收是否是正常的。
第一次握手:Client 什么都不能确认;Server 确认了对方发送正常,自己接受正常
第二次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:自己接收正常,对方发送正常
第三次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:自己发送、接收正常,对方发送接收正常
所以三次握手就能确认双发收发功能都正常,缺一不可。
为什么要传回 SYN

接收端传回发送端所发送的 SYN 是为了告诉发送端,我接收到的信息确实就是你所发送的信号了。

传了 SYN,为啥还要传 ACK?
双方通信无误必须是两者互相发送信息都无误。传了 SYN,证明发送方到接收方的通道没有问题,但是接收方到发送方的通道还需要 ACK 信号来进行验证。

为什么不需要四次握手 ?
完全可靠的通信协议是不存在的。在经过三次握手之后,客户端和服务端已经可以确认之前的通信状况,都收到了确认信息。所以即便再增加握手次数也不能保证后面的通信完全可靠,所以是没有必要的。
TCP 四次挥手 - 断开一个连接:
客户端-发送一个 FIN,用来关闭客户端到服务器的数据传送
服务器-收到这个 FIN,它发回一 个 FIN-ACK,确认序号为收到的序号加1 。和 SYN 一样,一个 FIN 将占用一个序号
服务器-发送一个FIN给客户端,此时服务器端变成LAST_ACK状态,等待最后客户端的ACK响应来关闭连接;
客户端-发回 FIN-ACK 报文确认,并将确认序号设置为收到序号加1,等待2MSL时间后客户端关闭。

为什么要四次挥手?
ACK报文是用来应答的,SYN报文是用来同步的。
当服务端收到FIN报文时,并不会立即关闭SOCKET,只能先回复一个ACK报文,告诉客户端,“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四次挥手。

TIME_WAIT等待状态:
客户端的TIME_WAIT状态也称为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL(Maximum Segment Lifetime,window MSL=2min,Linux MSL=60s,Unix MSL=30s),它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的,因为TCP报文段以IP数据报在网络内传输,而IP数据报则有限制其生存时间的TTL字段。

四次挥手释放连接时,客户端等待2MSL的意义?

总结来说就是为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失,从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。
为什么是2MSL?
MSL表示的是报文段在网络中的最长存活时间,是一个单位,客户端应该等待2MSL,因为有可能客户端发送的ACK报文,服务器端没收到,正常这个发送时间是1MSL,服务器端没收到后,会有重传机制(服务器端也有2MSL的倒数计时器,来作为重传的间隔时间,如果在2MSL时间内没收到客户端的回复,便会重发FIN包),重新发送Fin包到客户端,这个时间也是1MSL,客户端等待了2MSL在关闭,如果在2MSL时又收到了服务器端的请求,便会再发送一个ACK报文给服务器端,并会重启2MSL倒数计时器,这样保证了服务器端收到客户端ACK报文的消息可靠性。

假设客户端不等待2MSL,而是在发送完ACK之后直接释放关闭,一但这个ACK丢失的话,服务器就无法正常的进入关闭连接状态。理论上,四个报文都发送完毕,就可以直接进入CLOSE状态了,但是可能网络是不可靠的,有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

3.TCP怎么保证数据的可靠性?

TCP的可靠体现在TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认ACK、滑动窗口、确认重传机制、拥塞控制机制,在数据传完后,还会断开连接用来节约系统资源。
RTT:发送一个数据包到收到对应的ACK所花费的时间。
RTO:数据包重传的时间间隔(也叫超时时间)
1.TCP的确认重传机制保证了数据的可靠性:在TCP传送一个数据包时,它会把这个数据包放入重发队列中,同时启动计时器,如果收到了关于这个 包的确认信息,便将此数据包从队列中删除,如果在计时器超时的时候仍然没有收到确认信息,则需要重新发送该数据包。另外,TCP通过数据分段中的序列号来 保证所有传输的数据可以按照正常的顺序进行重组,从而保障数据传输的完整,RTO是通过RTT动态计算出的。
2.TCP的滑动窗口保证了数据的可靠性(建立在确认重传机制上):只有当窗口内的部分数据完整的发送和接收后,窗口才会滑动,总结起来就是使数据包完整的接收和发送,顺序的被接收和发送(从窗口外看)

4.什么是TCP的滑动窗口?

计算机网络面试题总结《持续更新》_第8张图片
在TCP会话的发送方存在四种状态,分别为发送并且确认ACK的、发送但是没有确认ACK的、没有发送但是准备发送的、没有发送并且不能发送的、窗口的范围在中间两部分,只有等到序列号为32,33,34,35的数据包全都收到ACK确认之后窗口才会向右滑动,如果只收到34,没收到32.33,窗口是不会滑动的,窗口不滑动时,也就不能准备发送52,53,54,55 。
计算机网络面试题总结《持续更新》_第9张图片

TCP会话的接收方分为三种状态,分别为 已经接受并且已经发送ACK确认的状态、没有接收但是可以接受的状态、没有接收并且不能接收的状态(达到了窗口的最大值)、中间部分为接收窗口,同发送方一样,只有当接收窗口内的一定范围内的序列号包全都接受完成后(接收的同时会返回给发送方ACK确认包),窗口才会滑动,如果只接受到了34,但是没有接收到32,33,窗口是不会滑动的,此时,接收方没有收到32,33的数据包,同时也不会发送32,33的ACK标识给发送方,发送方的32,33数据包由于在RTO时间内没有收到ACK标识,将重传数据包,这也就保证了接收数据包的顺序性和完整性,顺序性指虽然数据包在发送和接收过程中可以是乱序到达的,但是在滑动窗口处理接收和发送过程后会恢复顺序。完整性指如果接收方没有收到数据包,由于发送方没有收到接收方返回的ACK标志会启动确认重传机制(见问题4)。

总结:TCP使用滑动窗口做流量控制及乱序重排,滑动窗口可以保证TCP的数据可靠性(完整性,顺序性)和TCP的流控特性
滑动窗口的数据可靠性体现在完整性和顺序性上:
完整性:滑动窗口将使数据包完整的接收和发送、
顺序性:滑动窗口将使数据包顺序的发送和接收(窗口滑过的数据包具有顺序性),窗口内的数据包的发送和接收并不是顺序的。
流控特性体现在tcp报文段中的window字段上,该字段的意思是接收方通知发送方自己还有多少缓冲区(窗口大小)可以接受数据,发送方根据这个大小来合理的控制发送的数据量,也可以说设置一个合理的滑动窗口大小,因此滑动窗口的大小是可变的。

5.什么是HTTP协议?

HTTP是一个简单的请求-响应协议,它通常运行在TCP之上,属于应用层协议。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。
主要特点:支持客户/服务器模式、简单快速、灵活、无连接(即使在1.1引入长连接我们也说他的特点是无连接的)、无状态。
请求/响应步骤:
1.客户端向Web服务器发起tcp连接(三次握手)
2.发送http请求
3.服务器接收请求并返回HTTP响应
4.释放tcp连接(四次挥手):若该http为短连接,则服务器主动断开tcp连接,客户端被动断开连接,若该http为长连接,则该tcp连接会保持一段时间,在此时间内客户端都可以直接发起http请求
5.客户端浏览器解析响应的html内容

6.当在浏览器输入一个URL,按下回车之后经历的流程?

6.1 DNS域名解析:DNS解析的过程就是寻找哪台机器上有你需要资源的过程。当你在浏览器中输入一个地址时,例如www.baidu.com,其实不是百度网站真正意义上的地址。互联网上每一台计算机的唯一标识是它的IP地址,但是IP地址并不方便记忆。用户更喜欢用方便记忆的网址去寻找互联网上的其它计算机,也就是上面提到的百度的网址。所以互联网设计者需要在用户的方便性与可用性方面做一个权衡,这个权衡就是一个网址到IP地址的转换,这个过程就是DNS解析。它实际上充当了一个翻译的角色,实现了网址到IP地址的转换。网址到IP地址转换的过程是如何进行的?
6.1.1 解析流程: DNS解析是一个递归+迭代的过程
计算机网络面试题总结《持续更新》_第10张图片
上述图片是查找www.google.com的IP地址过程。首先在本地域名服务器中查询IP地址,如果没有找到的情况下,本地域名服务器会向根域名服务器发送一个请求,如果根域名服务器也不存在该域名时,本地域名会向com顶级域名服务器发送一个请求,依次类推下去。直到最后本地域名服务器得到google的IP地址并把它缓存到本地,供下次查询使用。从上述过程中,可以看出网址的解析是一个从右向左的过程: com -> google.com -> www.google.com。但是你是否发现少了点什么,根域名服务器的解析过程呢?事实上,真正的网址是www.google.com.,并不是我多打了一个.,这个.对应的就是根域名服务器,默认情况下所有的网址的最后一位都是.,既然是默认情况下,为了方便用户,通常都会省略,浏览器在请求DNS的时候会自动加上,所有网址真正的解析过程为: . -> .com -> google.com. -> www.google.com.。
6.1.2 DNS优化
了解了DNS的过程,可以为我们带来哪些?上文中请求到google的IP地址时,经历了8个步骤,这个过程中存在多个请求(同时存在UDP和TCP请求,为什么有两种请求方式,请自行查找)。如果每次都经过这么多步骤,是否太耗时间?如何减少该过程的步骤呢?那就是DNS缓存。
6.1.3 DNS缓存
DNS存在着多级缓存,从离浏览器的距离排序的话,有以下几种: 浏览器缓存,系统缓存,路由器缓存,本地域名服务器缓存,根域名服务器缓存,顶级域名服务器缓存,主域名服务器缓存。
在你的chrome浏览器中输入:chrome://dns/,你可以看到chrome浏览器的DNS缓存。
系统缓存主要存在/etc/hosts(Linux系统)中:
6.1.4 DNS负载均衡
不知道大家有没有思考过一个问题: DNS返回的IP地址是否每次都一样?如果每次都一样是否说明你请求的资源都位于同一台机器上面,那么这台机器需要多高的性能和储存才能满足亿万请求呢?其实真实的互联网世界背后存在成千上百台服务器,大型的网站甚至更多。但是在用户的眼中,它需要的只是处理他的请求,哪台机器处理请求并不重要。DNS可以返回一个合适的机器的IP给用户,例如可以根据每台机器的负载量,该机器离用户地理位置的距离等等,这种过程就是DNS负载均衡,又叫做DNS重定向。大家耳熟能详的CDN(Content Delivery Network,内容分发网络)就是利用DNS的重定向技术,DNS服务器会返回一个跟用户最接近的点的IP地址给用户,CDN(即最近的服务器)节点的服务器负责响应用户的请求,提供所需的内容。
6.2.客户端发起TCP连接(三次握手)
6.3.发送HTTP请求;
其实这部分又可以称为前端工程师眼中的HTTP,它主要发生在客户端。发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议中发送到服务器指定端口(HTTP协议80/8080, HTTPS协议443)。HTTP请求报文是由三部分组成:请求行,请求报头和请求正文。
请求行:

        格式如下:
        Method Request-URL HTTP-Version CRLF
       eg: GET index.html HTTP/1.1

常用的方法有: GET, POST, PUT, DELETE, OPTIONS, HEAD。

请求报头:

请求报头允许客户端向服务器传递请求的附加信息和客户端自身的信息。
PS: 客户端不一定特指浏览器,有时候也可使用Linux下的CURL命令以及HTTP客户端测试工具等。
常见的请求报头有: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent等。

HTTP分析

上图是使用Chrome开发者工具截取的对百度的HTTP请求以及响应报文,从图中可以看出,请求报头中使用了Accept, Accept-Encoding, Accept-Language, Cache-Control, Connection, Cookie等字段。Accept用于指定客户端用于接受哪些类型的信息,Accept-Encoding与Accept类似,它用于指定接受的编码方式。Connection设置为Keep-alive用于告诉客户端本次HTTP请求结束之后并不需要关闭TCP连接,这样可以使下次HTTP请求使用相同的TCP通道,节省TCP连接建立的时间。

请求正文:

当使用POST, PUT等方法时,通常需要客户端向服务器传递数据。这些数据就储存在请求正文中。在请求包头中有一些与请求正文相关的信息,例如: 现在的Web应用通常采用Rest架构,请求的数据格式一般为json。这时就需要设置Content-Type: application/json。

6.4.服务器处理请求并响应http请求
自然而然这部分对应的就是后端工程师眼中的HTTP。后端从在固定的端口接收到TCP报文开始,这一部分对应于编程语言中的socket。它会对TCP连接进行处理,对HTTP协议进行解析,并按照报文格式进一步封装成HTTP Request对象,供上层使用。这一部分工作一般是由Web服务器去进行,我使用过的Web服务器有Tomcat, Jetty和Netty等等。
HTTP响应报文也是由三部分组成:状态码、响应报头、响应报文。
6.5.浏览器解析渲染页面
6.6.连接结束(tcp四次挥手断开连接)

7.说一下Http常见的状态码?

状态码分类:
1XX:提示信息–表示请求已经接受,继续处理
2XX:成功–表示请求已被成功接受、理解、处理
3XX:重定向–要完成请求必须进行更进一步的操作
4XX:客户端错误–请求有语法错误或请求无法实现
5XX:服务端错误–服务器未能实现合法的请求

8.Get和Post请求的区别?

1.GET将请求信息放在请求行中(URL中),POST将请求信息放在请求体中;
2.GET请求符合幂等性和安全性,POST不符合;
3.GET请求参数有大小限制(浏览器和服务器对url长度都有限制,各浏览器对大小的限制也不同,一般为2KB~8KB),POST则没有限制;
4.POST比GET请求相对安全一些(本质上都不具有安全性,POST在请求体中也能看到请求信息);

9.Cookie和Session的区别?

由于http协议是无状态的,服务器并不知道每次接收到的请求是否是来自于同一个客户端的,这就导致了如果一个客户端访问一个带登录验证的服务器,每次访问将都需要登录,这显然是不合常理的,因此引入了一些会话技术,使客户端不用频繁的进行服务器的登录验证。
Cookie:是一种客户端的会话技术,是由服务器发送给客户端的特殊信息,以文本的形式存放在客户端,客户端再次请求的时候,会带着此Cookie一起访问服务器(此时Cookie存在于请求头中),服务器接收到后,会解析cookie生成与客户端相对应的内容。
Cookie的设置及发送过程:
计算机网络面试题总结《持续更新》_第11张图片

Session:是一种服务端的会话技术,将信息保存在服务器上,每次客户端请求服务器都会解析请求头中的JsessionID(利用Cookie实现),若存在此ID,说明该客户端访问过此服务器,并创建了对应的Session域(类似散列表),Session域中可能存有此客户端的一些信息。若不存在JsessionID,则服务器端会返回一个JsessionID给客户端,并为此创建一个Session域来保留此客户端的一些信息。
JsessionID的创建及发送过程:

计算机网络面试题总结《持续更新》_第12张图片

Cookie和Session的区别:
数据存放位置:Cookie数据存放在客户的浏览器上,Session数据放在服务器上;
安全性:Session相对于Cookie更安全;
性能:若考虑减轻服务器的负担,应当使用Cookie;

10.https数据传输流程?

HTTPS在传输数据之前需要客户端与服务器进行一个握手(TLS/SSL握手),在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL使用了非对称加密,对称加密以及hash等。具体过程请参考经典的阮一峰先生的博客TLS/SSL握手过程。

11.http和https的区别?

HTTP报文是包裹在TCP报文中发送的,服务器端收到TCP报文时会解包提取出HTTP报文。但是这个过程中存在一定的风险,HTTP报文是明文,如果中间被截取的话会存在一些信息泄露的风险。那么在进入TCP报文之前对HTTP做一次加密就可以解决这个问题了。HTTPS协议的本质就是HTTP + SSL(or TLS)。在HTTP报文进入TCP报文之前,先使用SSL对HTTP报文进行加密。从网络的层级结构看它位于HTTP协议与TCP协议之间。
计算机网络面试题总结《持续更新》_第13张图片

SSL协议:介于应用层与传输层之间,实际位于会话层,是为网络通信提供平安全及数据完整性的一种安全协议,是操作系统对外的API,SSL3.0后更名为TLS协议,采用身份验证和数据加密保证网络通信的安全和数据的完整性。
加密的方式:
对称加密:加密和解密都使用同一个公钥,速度快,安全性低
非对称加密:加密用公钥,解密用私钥,速度慢,安全性高
哈希算法(MD5):将任意长度的信息转换成固定长度的值,算法不可逆
数字签名:证明某个消息或者文件是某人发出/认同的
http和https的区别:
Http协议运行在TCP之上,明文传输,无状态连接,客户端与服务器端都无法验证对方的身份;Https是身披SSL(Secure Socket Layer)外壳的Http,运行于SSL上,SSL运行于TCP之上,是添加了数据加密和身份认证机制的HTTP。二者之间存在如下不同:
端口不同:Http与Http使用不同的连接方式,用的端口也不一样,前者是80,后者是443;
资源消耗:和HTTP通信相比,Https通信会由于加减密处理消耗更多的CPU和内存资源;
开销:Https通信需要证书,而证书一般需要向认证机构购买,Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

https一定安全吗?
不一定,正常情况下,用户输入URL时,只会输入域名(如www.baidu.com),浏览器默认帮你填充http://,很显然这是一个http请求,是不安全的,请求需要浏览器帮你跳转,此时可能会有被劫持的风险,可以使用正在推广的HSTS(HTTP Strict Transport Security) 来优化;、

12.什么是http的长连接和短连接?

HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。
详细见 https://www.cnblogs.com/gotodsp/p/6366163.html

13.什么是Socket? 就是tcp/ip协议的载体,网络进程与网络进程之间通过Socket通信。

计算机网络面试题总结《持续更新》_第14张图片
计算机网络面试题总结《持续更新》_第15张图片

你可能感兴趣的:(计算机网络)