博主现在大三在读,从三月开始找暑期实习,暑假准备去tx实习啦!总结下了很多面试真题,希望能帮助正在找工作的大家!相关参考都会标注原文链接,尊重原创!
参考:
当你的浏览器中地址栏输入地址并回车的一瞬间到页面能够展示回来,经历了什么?
当我们输入一个域名,回车时;首先检查本机的C:\Windows\System32\drivers\etc\hosts)
配置文件下有没有对应的域名映射
hosts
文件负责将主机名映射到相应的IP地址,通常用于补充或取代网络中DNS的功能。和DNS不同的是,计算机的用户可以直接对hosts文件进行控制。
有:直接返回对应的ip地址
没有:浏览器会发出一个 DNS请求到本地DNS服务器找对应的ip地址,本地DNS服务器一般都是你的网络接入服务器商提供,比如中国电信,中国移动
解析出IP地址后,浏览器根据IP地址和默认端口443向网站的服务器发起请求,建立TCP连接,三次握手:
建立好TCP连接后,浏览器通过http协议发送请求,请求数据包;
服务器处理请求,就将请求的数据返回给浏览器
浏览器与服务器数据传送完毕后,释放TCP连接,四次握手
浏览器对数据进行解析并渲染显示
两者都是传输层的协议
TCP
:传输控制协议,面向连接、点对点、可靠、提供全双工通信、面向字节流、有拥塞控制、流量控制、头部20BUDP
:用户数据包协议,无连接不可靠、面向报文、尽最大努力交付、无拥塞控制、首部开销小8B
慢开始&拥塞避免
起始时,拥塞窗口cwnd
为1,然后每经过一个RTT
传输轮次,拥塞窗口大小以2的指数增长,直到拥塞窗口大小为ssthresh
慢开始门限,即进入拥塞避免阶段,拥塞窗口随RTT线性增长每次+1,直到到达网络拥塞状态,将拥塞窗口大小置为1,慢开始门限置为原来的1/2;以此往复
快重传&快恢复
起始时,拥塞窗口cwnd
为1,然后每经过一个RTT
,拥塞窗口大小以2的制数形式增长,直到到慢开始门限,开始线性增长;在收到三个冗余的ACK后,执行快重传算法:慢开始门限降为拥塞窗口的1/2,再重新线性增长,以此往复;
采用滑动窗口机制,接收方根据自己的接收缓存大小,动态的调整发送方发送窗口的大小
rwnd
cwnd
发送窗口取决于rwnd
和cwnd
的最小值
HTTP
(HyperText Transfer Protocol:超文本传输协议)
TCP/IP
通信协议B/S
架构80
端口
HTTPS
(Hypertext Transfer Protocol Secure:超文本传输安全协议)是一种透过计算机网络进行安全通信的传输协议。
基于 HTTP 进行通信,但利用 SSL/TLS
来加密数据包。
SSL
(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全(Transport Layer Security,TLS
)是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层与应用层之间对网络连接进行加密。
HTTPS 开发的主要目的,是提供对网站服务器的身份认证,保护交换数据的隐私与完整性。
默认工作在 TCP 协议 443
端口,它的工作流程一般如以下方式:
1、TCP 三次同步握手
2、客户端验证服务器数字证书
3、DH 算法协商对称加密算法的密钥、hash 算法的密钥
4、SSL 安全加密隧道协商完成
5、网页以加密的方式传输,用协商的对称加密算法和密钥加密,保证数据机密性;用协商的hash算法进行数据完整性保护,保证数据不被篡改。
区别
HTTP
明文传输,数据都是未加密的,安全性较差,HTTPS
(SSL+HTTP) 数据传输过程是加密的,安全性较好。HTTPS
协议需要到 CA(Certificate Authority,数字证书认证机构) 申请证书,一般免费证书较少,因而需要一定费用。证书颁发机构如:Symantec、Comodo、GoDaddy 和 GlobalSign 等。HTTP
页面响应速度比 HTTPS
快,主要是因为 HTTP 使用 TCP 三次握手建立连接,客户端和服务器需要交换 3 个包,而 HTTPS除了 TCP 的三个包,还要加上 ssl 握手需要的 9 个包,所以一共是 12 个包。http
和 https
使用的是完全不同的连接方式,用的端口也不一样,前者是 80
,后者是 443
。HTTP1.0
header
的if=modified-Since
和Expires
作为缓存失效的标准HTTP1.1
206
),通过请求头的Range实现HTTP2.0
HTTP3.0
长连接(Persistent Connection)
HTTP1.1支持长连接和请求的流水线处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,在HTTP1.1中默认开启长连接keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接。
节约带宽
HTTP1.0中存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能。HTTP1.1支持只发送header信息(不带任何body信息),如果服务器认为客户端有权限请求服务器,则返回100,客户端接收到100才开始把请求body发送到服务器;如果返回401,客户端就可以不用发送请求body了节约了带宽。
HOST域
在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname),HTTP1.0没有host域。随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都支持host域,且请求消息中如果没有host域会报告一个错误(400 Bad Request)。
缓存处理
在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
错误通知的管理
在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
多路复用
HTTP2.0使用了多路复用的技术,做到同一个连接并发处理多个请求,而且并发请求的数量比HTTP1.1大了好几个数量级。HTTP1.1也可以多建立几个TCP连接,来支持处理更多并发的请求,但是创建TCP连接本身也是有开销的。
头部数据压缩
在HTTP1.1中,HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言,消息主体都会经过gzip压缩,或者本身传输的就是压缩过后的二进制文件,但状态行和头部却没有经过任何压缩,直接以纯文本传输。随着Web功能越来越复杂,每个页面产生的请求数也越来越多,导致消耗在头部的流量越来越多,尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容,完全是一种浪费。
HTTP1.1不支持header数据的压缩,HTTP2.0使用HPACK算法对header的数据进行压缩,
这样数据体积小了,在网络上传输就会更快。
服务器推送
服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源:HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始,然后在它解析和评估页面的时候,增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求,网络经常是空闲的和未充分使用的。
为了改善延迟,HTTP2.0引入了server push,
它允许服务端推送资源给浏览器,在浏览器明确地请求之前,免得客户端再次创建连接发送请求到服务器端获取。
这样客户端可以直接从本地加载这些资源,不用再通过网络。
状态码的职责是当客户端向服务器端发送请求时,描述返回的请求结果。借助状态码,用户可以知道服务器端是正常处理了请求,还是出现了错误。
面试官经常会问的一个问题是,如果TCP服务器宕机了,会发生什么?换句话说,TCP真的可靠吗?
这个问题需要从两个方面回答:
TCP如何保证可靠性?
首先,我们看看数据报不可靠有哪些问题,以及TCP是怎么解决的?
差错
:TCP通过首部的校验和,可以校验首部和和数据。这是一种端到端的校验,目的是检测数据在传输过程中的任何变化,如果收到对端的校验和有差错,TCP将这个包丢弃并且不确认。
丢包
:TCP发出一个数据包后,启动一个定时器,等待对端确认收到这个数据包,如果不能及时收到这个确认,将重发这个报文。
失序
:TCP承载于IP数据包来传输,IP包的到达可能会失序,因此TCP数据包的到达也可能失序,TCP对收到的数据包按照首部的序列号进行重新排序。
重复
:IP数据包会发生重复,TCP接收端根据TCP首部的序列号将重复的数据丢弃。
此外,确认数据包,也不能是确认了一个数据包再发送下一个数据包,这不利于并行的批量发送,我们可以批量的发送,再批量的确认。这里有两个问题需要考虑:1.接收方的处理能力,2.网络的处理能力。
先来看看接收方的处理能力。当接收方的硬件能力不如发送方,或者是系统繁忙,那发送过去的报文只能丢弃。要限制发送方的发送速度,接收方就要告诉发送方它的处理能力,好让发送发方限制它的发送速度就可以了,这就是滑动窗口的由来。
下面来看看网络处理能力。如果发送TCP数据包的速度快于中间某个路由器的发速度,路由器就开始丢包。导致较高的丢包率,如果TCP继续保持这个速度送数据,那么网络的性能就会极大的降低。这就需要拥塞控制算法。它分为两分,一个是慢启动,一个是拥塞避免。
慢启动指的就是TCP在一开始发送数据的时候以低速传输,只要能够得到对应报文的ACK,就以指数级的速度提高速率。当增长到一个阈值时,增长速度就变成线性增长,而不是指数级的。或者是丢包严重了,说明网络出现拥塞,要降低发送速率,进入拥塞避免阶段。
TCP并不能保证它所发送数据的可靠传输
可靠指的是什么,不可靠指的是什么?
上面我们讨论了TCP通过很多机制保证可靠,**这种可靠只是在端到端的通信上。**假设数据从A进程送到B进程,数据从A进程通过它所在主机TCP/IP协议栈向下传输,经过若干台路由器,通过进程B所在主机的TCP/IP协议栈向上传输,最后到达B进程。这些路由器没有TCP层,只是转发IP数据报,IP是个不可靠的协议。
TCP能够向进程B保证所有到达的数据是按序且未受损的。但有个问题,**TCP已经ACK的数据包实际上不一定会抵达应用进程。**比如,接收端TCP刚对数据进行ACK,但应用程序还没有读走,就崩溃了。
TCP为了保证可靠的传输,设计了复杂的头部
源端口和目的端口:主要是决定数据发给哪个应用程序的。
序列号:序号主要是为了解决乱序问题。
确认号:发送出去的包都需要确认,如果没有收到对方的确认包,就重新发送,直到送达。
首部长度:TCP头部的大小。
标志位:
窗口大小:主要用于流量控制。
校验和:对TCP头和数据进行校验。
紧急指针:当URG位为1,这个指针有效。
为什么建立连接是三次握手,四次不可以吗
# 第一次握手
Client什么都不能确认
Server确认了对方发送正常
# 第二次握手
Client确认:自己发送/接收正常,对方发送/接收正常
Server确认:自己接收正常 ,对方发送正常
# 第三次握手
Client确认:自己发送/接收正常, 对方发送/接收正常
Server确认:自己发送/接收正常,对方发送/接收正常
所以通过三次握手确认双方收发功能都正常,四次也可以但是显得比较多余
如果两次握手会怎么样
防止已失效的连接请求又传送到服务器端,因而产生错误
有这样一种情况,当A发送一个消息给B,但是由于网络原因,消息被阻塞在了某个节点,然后阻塞的时间超出设定的时间,A会认为这个消息丢失了,然后重新发送消息,然后AB正常连接通信,当A和B通信完成后并释放连接后,这个被A认为失效的消息,到达了B,对于B而言,以为这是一个新的请求链接消息,就向A发送确认,对于A而言,它认为没有给B再次发送消息(因为上次的通话已经结束)所有A不会理睬B的这个确认,但是B则会一直等待A的消息,这就导致了B的时间被浪费(对于服务器而言,CPU等资源是一种浪费),这样是不可行的,这就是为什么不能两次握手的原因了。
为什么是四次挥手,而不是三次
因为TCP是一个全双工协议,必须单独拆除每一条信道。如果是三次挥手,服务端在收到FIN消息之后,需要同时回复ACK和Server端的FIN消息,如果服务端在该连接上面并没有额外的消息要处理,那么是可以的,如果服务端还有其他的消息待传送,那么这样的三次挥手就不能满足条件
为什么四次挥手最后要等待2MSL
为实现TCP这种全双工连接的可靠释放
这样可让TCP再次发送最后的ACK以防这个ACK丢失(另一端超时并重发最后的FIN)这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间,定义这个连接的插口(客户的IP地址和端口号,服务器的IP地址和端口号)不能再被使用。这个连接只能在2MSL结束后才能再被使用。
为使旧的数据包在网络因过期而消失
每个具体TCP实现必须选择一个报文段最大生存时间MSL,它是任何报文段被丢弃前在网络内的最长时间,一来一回就是2MSL
1️⃣ 发送方产生粘包
采用TCP协议传输数据的客户端与服务器经常是保持一个长连接的状态(一次连接发一次数据不存在粘包),双方在连接不断开的情况下,可以一直传输数据;但当发送的数据包过于的小时,那么TCP协议默认的会启用Nagle算法,将这些较小的数据包进行合并发送(缓冲区数据发送是一个堆压的过程);这个合并过程就是在发送缓冲区中进行的,也就是说数据发送出来它已经是粘包的状态了。
2️⃣ 接收方产生粘包
接收方采用TCP协议接收数据时的过程是这样的:数据到底接收方,从网络模型的下方传递至传输层,传输层的TCP协议处理是将其放置接收缓冲区,然后由应用层来主动获取(C语言用recv、read等函数);这时会出现一个问题,就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来,而下一个数据又到来并有一部分放入的缓冲区末尾,等我们读取数据时就是一个粘包。(放数据的速度 > 应用层拿数据速度)