Http相关面试题(含答案)

1.HTTP协议

• http协议是什么

HTTP(HyperText Transfer Protocol:超文本传输协议)

超文本可以说是"超级文本"或者说是"带链接文本"。超链接文本可以有图片、动图、文字、视频。从本质上说它是一个内容文本，我们对网站的浏览，实际上是对内容的浏览。对于这些内容，都有统一的路径，我们称之为URL地址

http(s): //<主机>:<端口>/<路径>
http:表示协议，有http和https协议
主机可以是ip也可以是域名，如果是域名，会使用到DNS服务，将其转换为ip地址。
端口：80端口表示http端口，443端口表示https端口。
路径：指向特定的内容

https://www.imooc.com/
https://www.baidu.com/
https://www.taobao.com/
以上都是网站地址。
HTTP协议是可靠的数据传输协议。
可靠性是依赖于传输层的TCP协议来实现的。也就是说，HTTP协议的底层是TCP协议通过TCP协议的可靠性从而保证HTTP协议也是可靠的。
数据包括文本、图片、文件、动图、视频、音频。这些构成了web网站内容，我们平时都是对这些内容进行浏览

2.HTTP和HTTPS的区别

• 端口：http默认端口是80，https默认端口是443
• 安全性和资源消耗:
  • HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。
  • HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，使用https协议可以认证用户和服务器，确保数据发送到正确的客户机和服务器。HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
  • HTTPS连接缓存不如HTTP高效，大流量网站如非必要也不会采用，流量成本太高。

所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

3.get请求和post请求有什么区别

• url可见性
  • get，参数url可见
  • post，url参数不可见
• 数据传输上：
  • get，通过拼接url进行传递参数
  • post，通过body体传输参数
• 缓存性
  • get请求时可以缓存的
  • post请求不可以缓存
• 后退页面的反应
  • get请求页面后退时，不产生影响
  • post请求页面后退时，会重新提交请求
• 传输数据大小
  • get一般传输数据大小不超过2k-4k（根据浏览器不同，限制不一样，但相差不大）
  • post请求传输数据的大小根据php.ini 配置文件设定，也可以无限大。
• 安全性
  • 原则上post肯定要比get安全，毕竟传输参数时url不可见，但也挡不住部分人闲的没事在那抓包玩。安全性个人觉得是没多大区别的，防君子不防小人就是这个道理。对传递的参数进行加密，其实都一样。
• 数据包
  • GET产生一个TCP数据包；对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
  • POST产生两个TCP数据包。POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

4.三次握手和四次挥手

• 第一次握手：客户端发送网络包，服务端收到了。
  这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
• 第二次握手：服务端发包，客户端收到了。
  这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
• 第三次握手：客户端发包，服务端收到了。
  这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

因此，需要三次握手才能确认双方的接收与发送能力是否正常。

• 第一次挥手︰主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送﹐也就是主动关闭方告诉被动关闭方:我已经不会再给你发数据了(当然，在fin包之前发送出去的数据﹐如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是﹐此时主动关闭方还可以接受数据。
• 第二次挥手:被动关闭方收到FIN包后﹐发送一个ACK给对方﹐确认序号为收到序号+1(与SYN相同，一个FIN占用一个序号)。
• 第三次挥手∶被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送﹐也就是告诉主动关闭方﹐我的数据也发送完了﹐不会再给你发数据了。
• 第四次挥手:主动关闭方收到FIN后﹐发送一个ACK给被动关闭方﹐确认序号为收到序号+1，至此﹐完成四次挥手。

挥手为什么要四次

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

5.http状态码

• 100-199 用于指定客户端应相应的某些动作。

• 200-299 用于表示请求成功。

• 300-399 用于已经移动的文件并且常被包含在定位头信息中指定新的地址信息。

• 400-499 用于指出客户端的错误。

• 500-599 用于支持服务器错误。

6.http请求报文

• HTTP 请求报文由请求行、请求头、空行和请求包体(body)组成

• 示例

GET / HTTP/1.1     
Host: www.baidu.com
Connection: keep-alive
Cache-Control: max-age=0
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: BIDUPSID=8B0207CE0B6364E5934651E84F17999B; PSTM=1619707475; 

6.1请求行

• 主要描述了客户端想要如何操作服务端的资源；请求行由三部分构成：
  • 请求方法：表示对资源期望进行何种操作，常用的如 GET、POST
  • 请求目标：通常是一个 URL ，表明了要操作的资源。
  • 版本号：表示报文使用的 HTTP 协议版本。

这三个部分通常使用空格(space)来分隔，最后要用 CRLF 换行表示结束。

GET / HTTP/1.1  

6.2请求头

HTTP的报文头，报文头包含若干个属性，格式为“属性名:属性值”，服务端据此获取客户端的信息。与缓存相关的规则信息，均包含在header中，请求头可大致分为四种类型：通用首部字段、请求首部字段、响应首部字段、实体首部字段。

#通用头标：即可用于请求，也可用于响应，是作为一个整体而不是特定资源与事务相关联。
#请求头标：允许客户端传递关于自身的信息和希望的响应形式。
#响应头标：服务器和于传递自身信息的响应。
#实体头标：定义被传送资源的信息。即可用于请求，也可用于响应。

• Accept：指定客户端能够接收的内容类型。

• Accept-Charset：浏览器可以接受的字符编码集。

• Accept-Encoding：指定浏览器可以支持的web服务器返回内容压缩编码类型。

• Accept-Language：浏览器可接受的语言。

• Accept-Ranges：可以请求网页实体的一个或者多个子范围字段。

• AuthorizationHTTP：授权的授权证书。

• Cache-Control：指定请求和响应遵循的缓存机制。

• Connection：表示是否需要持久连接。（HTTP 1.1默认进行持久连接）

• CookieHTTP：请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。

• Content-Length：请求的内容长度。

• Content-Type：请求的与实体对应的MIME信息。

• Date：请求发送的日期和时间。

• Expect：请求的特定的服务器行为。

• From：发出请求的用户的Email。

• Host：指定请求的服务器的域名和端口号。

• If-Match：只有请求内容与实体相匹配才有效。

• If-Modified-Since：如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码。

• If-None-Match：如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变。

• If-Range：如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。

• If-Unmodified-Since：只在实体在指定时间之后未被修改才请求成功。

• Max-Forwards：限制信息通过代理和网关传送的时间。

• Pragma：用来包含实现特定的指令。

• Proxy-Authorization：连接到代理的授权证书。

• Range：只请求实体的一部分，指定范围。

• Referer：先前网页的地址，当前请求网页紧随其后,即来路。

• TE：客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息。

• Upgrade：向服务器指定某种传输协议以便服务器进行转换（如果支持。

• User-AgentUser-Agent：的内容包含发出请求的用户信息。

• Via：通知中间网关或代理服务器地址，通信协议。

• Warning：关于消息实体的警告信息

7.相应报文

响应行/状态行
HTTP/1.1 200 OK # HTTP协议版本 状态码 状态描述
— 响应头 —
Server: Tengine # 服务器名称
Content-Type: text/html; charset=UTF-8 # 内容类型
Transfer-Encoding: chunked # 发送给客户端内容不确定内容长度，发送结束的标记是0\r\n, Content-Length表示服务端确定发送给客户端的内容大小，但是二者只能用其一。
Connection: keep-alive # 和客户端保持长连接
Date: Fri, 23 Nov 2018 02:01:05 GMT # 服务端的响应时间
空行
响应体

… # 响应给客户端的数据
原始响应报文说明:

HTTP/1.1 200 OK\r\n
Server: Tengine\r\n
Content-Type: text/html; charset=UTF-8\r\n
Transfer-Encoding: chunked\r\n
Connection: keep-alive\r\n
Date: Fri, 23 Nov 2018 02:01:05 GMT\r\n
\r\n(响应头信息后面还有一个单独的’\r\n’不能省略)

8.https的工作原理

一、首先HTTP请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥（RSA加密）等进行校验；
二、客户端如果校验通过后，就根据证书的公钥的有效， 生成随机数，随机数使用公钥进行加密（RSA加密）；
三、消息体产生的后，对它的摘要进行MD5（或者SHA1）算法加密，此时就得到了RSA签名；
四、发送给服务端，此时只有服务端（RSA私钥）能解密。
五、解密得到的随机数，再用AES加密，作为密钥（此时的密钥只有客户端和服务端知道）。

9.tcp和udp的区别

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接

2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付

3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）

4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

5、TCP首部开销20字节;UDP的首部开销小，只有8个字节

可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付

3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）

4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

5、TCP首部开销20字节;UDP的首部开销小，只有8个字节

6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道