文章目录

HTTP基础知识整理

1、浏览器中网址访问过程详解

当我们在浏览器访问一个网址 https://xwder.com 并显示出网站内容整个过程是怎么样的?大致可以分为下面几个过程:

(1)浏览器本身是一个客户端,当你输入URL的时候,首先浏览器会去请求DNS服务器,通过DNS获取相应的域名对应的IP

(2)然后通过IP地址找到IP对应的服务器后,要求建立TCP连接

(3)浏览器发送完HTTP Request(请求)包后,服务器接收到请求包之后才开始处理请求包

(4)在服务器收到请求之后,服务器调用自身服务,返回HTTP Response(响应)包

(5)客户端收到来自服务器的响应后开始渲染这个Response包里的主体(body),等收到全部的内容随后断开与该服务器之间的TCP连接。

2、DNS解析过程

(1)当浏览器输入域名,本地操作系统先检查本地hosts文件(windows文件地址:C:\Windows\System32\drivers\etc\hosts,Linux:/etc/hosts),域名IP映射文件,(这里有个小技巧,当你想指定域名解析到指定IP可以在这里配置,或者屏蔽某个域名的联网访问,可以将该域名解析到本地127.0.0.1),如果本地存在则完成域名解析过程;

(2)如果hosts里没有这个域名的映射,则查找本地DNS解析器缓存,是否有这个网址映射关系,如果有,直接返回,完成域名解析。

(3)如果hosts与本地DNS解析器缓存都没有相应的网址映射关系,首先会找TCP/IP参数中设置的首选DNS服务器,在此我们叫它本地DNS服务器,此服务器收到查询时,如果要查询的域名,包含在本地配置区域资源中,则返回解析结果给客户机,完成域名解析,此解析具有权威性。

(4)如果要查询的域名,不由本地DNS服务器区域解析,但该服务器已缓存了此网址映射关系,则调用这个IP地址映射,完成域名解析,此解析不具有权威性。

(5)如果本地DNS服务器本地区域文件与缓存解析都失效,则根据本地DNS服务器的设置(是否设置转发器)进行查询,如果未用转发模式,本地DNS就把请求发至13台根DNS服务器,根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理,并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后,将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后,如果自己无法解析,它就会找一个管理.com域的下一级DNS服务器地址(xwder.com)给本地DNS服务器。当本地DNS服务器收到这个地址后,就会找xwder.com域服务器,重复上面的动作,进行查询,直至找到xwder.com主机。

(6)如果用的是转发模式,此DNS服务器就会把请求转发至上一级DNS服务器,由上一级服务器进行解析,上一级服务器如果不能解析,或找根DNS或把转请求转至上上级,以此循环。不管是本地DNS服务器用是是转发,还是根提示,最后都是把结果返回给本地DNS服务器,由此DNS服务器再返回给客户机。

参考:

3、tcp/ip的分层

TCP/IP协议族分为4层:应用层、传输层、网络层、数据链路层

  • 应用层:主要是与应用通信使用到的协议,比如:FTP、DNS、HTTP
  • 传输层:为应用层提供在两台机器之间数据传输,有两种协议:TCP、UDP
  • 网络层:两台机器之间在传输的过程中会经过多个路由器有多条路线,网络层主要是从中选择一条路线
  • 数据链路层:用来处理连接网络的硬件部分,比如说网卡、设备驱动等

TCP/IP 和 ISO/OSI协议分层

ISO/OSI模型,即开放式通信系统互联参考模型(Open System Interconnection Reference Model),是国际标准化组织(ISO)提出的一个试图使各种计算机在世界范围内互连为网络的标准框架,简称OSI。

TCP/IP协议模型(Transmission Control Protocol/Internet Protocol),包含了一系列构成互联网基础的网络协议,是Internet的核心协议,通过20多年的发展已日渐成熟,并被广泛应用于局域网和广域网中,目前已成为事实上的国际标准。TCP/IP协议簇是一组不同层次上的多个协议的组合,通常被认为是一个四层协议系统,与OSI的七层模型相对应。

参考:

TCP/IP协议分层详解

一文搞懂TCP与UDP的区别

4、在tcp/ip的分层里面,当客户端发起http请求到达服务端的过程中,数据包的封装以及解包的过程是怎样的?

HTTP访问分层

在这个分层中,每次网络请求都会按照分层的顺序与对方进行通信,发送端从应用层往下走,接收端从数据链路层往上走;以Http来举例的话:

  1. 客户端在应用层(Http协议)发起一个HTTP请求
  2. 在传输层(TCP协议)把从应用层收到的Http请求数据包分隔成小的数据包,并打好序
  3. 网络层(IP协议)收到数据包后选择发送路径
  4. 服务器收到数据后按照顺序往上发送,直到应用层收到数据

在发送方每经过一层,就会被加上该层的首部信息,当接收方接受到数据后,在每一个层会去掉对应的首部信息。

5、TCP如何保证数据可靠到达目的地?

TCP协议采用的三次握手策略

  • 第一次握手:建立连接时,客户端发送 syn 包(syn=j)到服务器,并进入 SYN_SEND 状态,等待服务器确认;
  • 第二次握手:服务器收到 syn 包,必须确认客户的 SYN(ack=j+1),同时自己也发送一个 SYN 包(syn=k),即 SYN+ACK 包,此时服务器进入 SYN_RECV 状态;
  • 第三次握手:客户端收到服务器的 SYN+ACK 包,向服务器发送确认包 ACK(ack=k+1),此包发送完毕,客户端和服务器进入 ESTABLISHED 状态,完成三次握手。

TCP协议采用的三次握手策略

TCP协议采用的三次握手动图

6、为什么是三次握手,而不是两次或者4次呢?

第一次握手

客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后,客户端便进入 SYN-SENT 状态。

第二次握手

服务端收到连接请求报文段后,如果同意连接,则会发送一个应答,该应答中也会包含自身的数据通讯初始序号,发送完成后便进入 SYN-RECEIVED 状态。

第三次握手

当客户端收到连接同意的应答后,还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态,服务端收到这个应答后也进入 ESTABLISHED 状态,此时连接建立成功。

原因:

这里可能大家会有个疑惑:为什么 TCP 建立连接需要三次握手,而不是两次?这是因为这是为了防止出现失效的连接请求报文段被服务端接收的情况,从而产生错误。

假如说是两次握手,如果客户端自己处理异常或者是服务器返回的ack消息丢失,那么客服端会认为连接建立失败,再次重新发送请求建立连接,但是服务端却无感知,以为连接以及正常建立,导致服务器建立无用的连接,浪费资源

假如四次握手,如果三次已经足够,那就不需要四次了。如果四次的话,最后一个ACK丢失,那么又会出现两次握手的问题。

7、TCP断开链接四次挥手

TCP 是全双工的,在断开连接时两端都需要发送 FIN 和 ACK。

  • 客户端向服务器发送FIN希望断开连接请求。
  • 服务器向客户端发送ACK,表示同意释放连接。
  • 服务器向客户端发送一个FIN表示希望断开连接。
  • 客户端向服务器返回一个ACK表示同意释放连接。

tcp链接断开四次挥手

第一次握手

若客户端 A 认为数据发送完成,则它需要向服务端 B 发送连接释放请求。

第二次握手

B 收到连接释放请求后,会告诉应用层要释放 TCP 链接。然后会发送 ACK 包,并进入 CLOSE_WAIT 状态,此时表明 A 到 B 的连接已经释放,不再接收 A 发的数据了。但是因为 TCP 连接是双向的,所以 B 仍旧可以发送数据给 A。

第三次握手

B 如果此时还有没发完的数据会继续发送,完毕后会向 A 发送连接释放请求,然后 B 便进入 LAST-ACK 状态。

第四次握手

A 收到释放请求后,向 B 发送确认应答,此时 A 进入 TIME-WAIT 状态。该状态会持续 2MSL(最大段生存期,指报文段在网络中生存的时间,超时会被抛弃) 时间,若该时间段内没有 B 的重发请求的话,就进入 CLOSED 状态。当 B 收到确认应答后,也便进入 CLOSED 状态。

因为当服务器收到客户端断开连接的请求后,服务器不能立即断开连接,因为可能服务器端还有数据未发送完成,所以只能回复一个ACK表示我已收到消息;等服务器端数据发送完成之后再发送一个FIN希望端开连接的消息,客户端回复ACK之后,就可以安全断开了

8、为什么说Http协议无状态协议?怎么解决Http协议无状态?

​ 本身HTTP协议是不保存状态的,自身不对请求和响应直接的通信状态进行保存,所以是无状态的协议。因为在有些场景下我们需要保存用户的登录信息,所以引入了cookie来管理状态。客户端第一次请求服务器的时候,服务器会生成cookie添加在响应头里面,以后客户端的每次请求都会带上这个cookie信息。

  • Cookie是有服务器生成,写入到请求的响应头中,浏览器会保存;服务器通过Set-Cookie字段向客户端设置Cookie,属性:
  1. Name=value 设置cookie的名字和值
  2. expires 设置Cookie的有效期
  3. domain=域名 表示只能在哪个域名下生效
  4. secure表示只能在Https的通信时才发送cookie
  5. HttpOnly 表示不能被javascript访问
  • Session也是服务器生成的,表示服务器中的一片内存,每个客服端对应一个Session,客户端之间的Session相互独立;每次客户端发起请求,都会带上Cookie,Cookie里面一般都会有一个JSESSIONID,服务器就是通过这个JESSIONID来找到客户端对应Session,所以一般用户的登录信息都会存放在Session;这样也解决了Http协议无状态的问题

10、Http协议中有那些请求方式

  • GET : 获取资源; 所以查询操作一般用GET
  • POST: 传输实体主体, 创建更新操作用POST
  • PUT: 传输文件
  • HEAD: 获取报文首部,如果想要查询某个请求的头信息可以用这个方法
  • DELETE: 删除资源,所以删除操作用DELETE
  • OPTIONS: 询问服务器支持哪些方法,响应头中返回 Allow: GET,POST,HEAD
  • TRACE: 追踪路径;在请求头中在Max-Forwards字段设置数字,每经过一个服务器该数字就减一,当到0的时候就直接返回,一般通过该方法检查请求发送出去是否被篡改

11、Http如何实现持久连接的呢?

在HTTP协议的早期,每进行一次HTTP通信就要断开一次tcp连接,当时传输的内容少还能接受,现在每个网页一般的会包含大量的图片,每次请求都会造成TCP连接的连接和断开,增加通信的开销。

为了解决这个问题所以想出了持久连接的方法,也叫做keep-alive,只要一端没有提出断开连接就会一直保持TCP连接的状态。持久化连接使的客户端可以同时并发发送多个请求,不用一个接着一个的等待响应。

12、常见Http协议状态码有哪些?

  • 2xx: 成功状态码,表示请求正常处理完毕
  • 3xx: 重定向状态码,表示需要附加操作才能完成成请求
  • 4xx: 客户端错误状态码
  • 5xx: 服务器错误状态码

常见的状态码有: 200(请求正常处理完成)、204(请求处理成功,但是没有资源返回)、206(表示客户端进行了范围请求,响应报文中包含了Content-Range)、301(永久性重定向,请求的资源以及被分配到了新的地址)、302(临时重定向,希望用户并且请求新地址)、400(客户端请求报文出现错误,通常是参数错误)、401(客户端未认证错误)、403(没有权限访问该资源)、404(未找到请求的资源)、405(不支持该请求方法,如果服务器支持GET,客户端用POST请求就会出现这个错误码)、500(服务器异常)、503(服务器不能提供服务)

13、HTTP报文由哪些部分组成?

  • 请求报文包含三部分:
  1. 请求行:包含请求方法、URI、HTTP版本信息
  2. 请求首部字段
  3. 请求内容实体
  • 响应报文包含三部分:
  1. 状态行:包含HTTP版本、状态码、状态码的原因短语
  2. 响应首部字段
  3. 响应内容实体

14、Http有哪些问题,什么是https?

什么是HTTP?

超文本传输协议,是一个基于请求与响应,无状态的,应用层的协议,常基于TCP/IP协议传输数据,互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。

什么是HTTPS?

《图解HTTP》这本书中曾提过HTTPS是身披SSL外壳的HTTP。HTTPS是一种通过计算机网络进行安全通信的传输协议,经由HTTP进行通信,利用SSL/TLS建立全信道,加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证,同时保护交换数据的隐私与完整性。

PS:TLS是传输层加密协议,前身是SSL协议,由网景公司1995年发布,有时候两者不区分。

Http的问题:

  • 通信使用明文不加密,内容可能被窃听
  • 不验证通信方身份,可能遭到伪装
  • 无法验证报文完整性,可能被篡改 HTTPS就是HTTP加上SSL加密处理(一般是SSL安全通信线路)+认证+完整性保护

15、HTTPS是如何保证数据安全的

首先需要说到两种加密机制:

  • 对称加密:客户端和服务器都使用了同一个密钥加密,效率较高
  • 非对称加密:分为了公开密钥和私有密钥,公开密钥可以在网络上传输,使用公开密钥加密后的内容只有私有密钥才能解密,效率较低

由于这两个加密的特别,HTTPS采用的时候混合加密机制,在交换密钥的阶段使用的是非对称加密,在建立通信交换报文阶段采用的是对称加密

以访问 https://silently9527.cn 举例

  1. 浏览器向服务器发起请求,服务器在接收到请求之后,返回证书和密钥
  2. 浏览器向第三方证书机构验证证书是否合法,如果不合法浏览器将会弹出警告页面,让用户选择是否继续访问
  3. 如果证书合法浏览器生成随机串,使用公钥加密发送给服务器,服务器使用私钥解密出随机串,服务器使用随机串加密内容返回给客户端
  4. 之后客户端和服务器端都将通过随机串进行对称加密

https证书加密

16、为什么需要证书认证机构,不要https就不安全了吗?

虽然https是可以加密的,但是因为请求还是可以被劫持,如何让客户端知道返回给自己的公钥是真实服务器给的而不是攻击者给的;这就需要验证证书的合法性,所以需要引入第三方认证机构。通常https的证书需要到第三方机构去申请购买,如果是我们自己生成的https证书浏览器验证不过会弹出警告。

17、浏览器是如何保证证书验证的过程是安全的呢?

浏览器在向证书认证中心验证证书的过程使用的也是非对称加密,这里想要让公钥能够安全的转交给客户端,是非常困难的,所以浏览器的开发商通常会在浏览器内部植入常用认证机构的公开密钥。

参考 HTTP和HTTPS协议,看一篇就够了

整理自:《面试官不讲武德》对Java初级程序猿死命摩擦Http协议