文章目录
一、HTTP协议的特点
二、浏览器中输入URL返回页面过程(重)
三、HTTP状态码
四、HTTP相关协议对比
五、HTTP报文格式
六、GET、POST的区别(重)
七、什么是数字证书(重)
八、DNS的解析过程
九、Cookie与Session
十、对称加密和非对称加密
本文对于计算机面试、笔试过程中经常被问到的计算机网络类问题,做一个梳理总结,方便自己查看学习,同时也希望为其他找工作、学习的伙伴提供一个参考。
本文是第二篇,第一篇TCP、IP部分可查阅 计算机网络常见面试题(一):TCP/IP五层模型、TCP三次握手、四次挥手,TCP传输可靠性保障、ARQ协议
HTTP是一种不保存状态,即无状态(stateless)协议。也就是说HTTP协议自身不对请求和响应之间的通信状态进行保存。那么我们如何保存用户状态呢?Session机制的存在就是为了解决这个问题,Session的主要作用就是通过服务端记录用户的状态。典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为HTTP协议是无状态的。服务端给特定的用户创建特定的Session之后就可以标识这个用户并且跟踪这个用户了(一般情况下,服务器会在一定时间内保存这个Session,过了时间限制,就会销毁这个Session)。
在服务端保存Session的方法很多,最常用的就是内存和数据库(比如是使用内存数据库redis保存)。既然Session存放在服务器端,那么我们如何实现Session跟踪呢?大部分情况下,我们都是通过在Cookie中附加一个SessionID来方式来跟踪。
Cookie被禁用怎么办?
默认情况下禁用 Cookie 后,Session 是无法正常使用的;但可以通过一些手段绕过Cookie继续运行Session——URL 中携带 SessionID、隐藏表单字段传递 SessionID。
状态码 | 解释 |
---|---|
1xx | 响应中——临时状态码,服务器收到请求,需要请求者继续执行操作。如100(Continue),客户端应继续发送请求 |
2xx | 正常——请求正常处理完毕 |
3xx | 重定向,需要进一步操作已完成请求 |
4xx | 客户端错误,服务器无法处理请求 |
5xx | 服务器处理请求出错 |
HTTP | HTTPS |
---|---|
超文本传输协议,信息明文传输 | 具有安全性的ss加密传输协议 |
80端口 | 443端口 |
运行在TCP协议上 | 运行在SSL协议上,SSL运行在TCP之上 |
需要向CA机构申请证书,一般需要一定的费用 |
HTTP1.0 | HTTP1.1 | |
---|---|---|
连接方式 | 短连接(浏览器与服务器每进行一次HTTP操作,就建立一次连接,任务结束后就中断连接) | 长连接(复用TCP连接,多个HTTP请求可以复用同一个TCP连接,节省TCP连接建立、断开的消耗) |
状态响应码 | 新增大量的状态码,光是错误响应状态码新增24种,如 -100(Continue):在请求大资源前的预热请求 -206(PartialContent):范围请求的标识码 -409(Confict):请求与当前资源的规定冲突 | |
缓存处理 | 使用header里的if-Modified-Since,Expireez作为缓存判断标准 | 引入更多的缓存策略如if-Unmodified-Since等 |
带宽优化及网络连接的使用 | 存在浪费带宽的现象,例如客户端只需要某对象的部分,而服务器却将整个对象传送过来,且不支持断点续传功能 | 在请求头引入range头域,它允许只请求资源的某部分 |
Host头处理 | 在请求头中新增Host字段 |
HTTP1.1 | HTTP2.0 | |
---|---|---|
新的二进制格式 | 基于文本格式传输数据 | 二进制格式传输数据,解析更高效 |
多路复用 | 在一个连接里,充许同时发送多个请求或响应,能够并行的传输而不被阻塞,避免HTTP1.1出现"队头堵塞"问题 | |
头部压缩 | header带有大量信息,而且每次都要重复发送 | 把header从数据中分离,并封装成头帧和数据帧,使用特定算法压缩头帧。且HTTP2.0在客户端和服务器端记录了之前发送的键值对,对于相同的数据,不会重复发送。比如请求a发送了所有的头信息字段,请求b则只需要发送差异数据,这样就减少冗余数据,降低开销 |
服务端推送 | 允许服务器向客户端推送资源,而无需客户端发送请求到服务器获取 |
HTTP2.0 | HTTP3.0 | |
---|---|---|
传输层协议 | 使用TCP传输层协议 | 使用UDP上的QUIC协议作为传输层协议。QUIC是一种旨在提供类似于TCP的可靠传输服务的协议,但它运行在UDP上,从而提供了更低的延迟和更快的连接恢复 |
对头阻塞 | 虽然HTTP/2引入了多路复用来减少队头阻塞但因为仍然是基于TCP的,所以如果一个数据包丢失,会导致整个连接被阻塞,即所有流都会受到影响 | 由于QUIC是基于UDP的,即使一个数据包丢失,也不会阻塞其他数据包的传输。每个流都是独立的,这意味着一个流中的数据包丢失只会影响该特定流,不会影响其他流 |
连接建立时间 | 使用TCP进行连接建立,包括TCP的三次握手和TLS握手,这通常需要至少一个往返时间(RTT) | 使用QUIC可以支持O-RTT(Zero Round Trip Time)连接恢复,这意味着在某些情况下,客户端可以在不需要等待服务器确认的情况下发送数据,从而减少了连接建立时间 |
加密 | 可以与HTTPS结合使用,加密发生在TLS层,HTTP/2本身不包含加密机制 | 所有的QUIC流量默认都是加密的,这增加了安全性,并且QUIC的加密层位于协议的较低层,有助于提高性能 |
拥塞控制 | 使用TCP的拥塞控制机制 | QUIC包含自己的拥塞控制算法,可以在网络条件变化时动态调整数据传输速率,从而优化网络性能 |
移动性支持 | 当IP地址改变时,如设备在移动网络和Wi-Fi之间切换,TCP连接需要重新建立 | 由于QUIC在UDP上运行,它可以更好地处理IP地址的变化,从而保持连接的连续性 |
错误处理 | 错误处理相对简单,可能会影响到整个连接 | 支持更细粒度的错误处理机制,可以仅影响到特定的流或帧 |
HTTP报文分为请求报文(request message)与响应报文(response message)。
HTTP请求包含四个组成部分:请求行、请求头、空行、请求体
请求报文实例
POST /demo/index.html HTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection: Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=dabin 请求体
浏览器向主机发起一个HTTP-GET方法报文请求。请求中包含访问的URL,也就是http://www.baidu.com/ ,KeepAlive,长连接,还有User-Agent用户浏览器操作系统信息,编码等。值得一提的是Accep-Encoding和Cookies项。Accept-Encoding一般采用gzip,压缩之后传输html文件。Cookies如果是首次访问,会提示服务器建立用户缓存信息,如果不是,可以利用Cookies对应键值,找到相应缓存,缓存里面存放着用户名,密码和一些用户设置项。
Content-Type,描述本次请求的body内容是什么格式。常见Content-Type格式:text/html html格式;text/plain 纯文本格式;application/json POST专用,用来告诉服务端消息主体是序列化后的 JSON 字符串;multipart/form-data POST专用,用以支持向服务器发送二进制数据,以便可以在 POST 请求中实现文件上传等功能
Accept,指浏览器或其他客户端可以接受的 MIME(Multipurpose Internet Mail Extensions,多用途互联网邮件扩展)文件类型,服务器可以根据它判断并返回适当的文件格式
Content-Type:application/json;charset=UTF-8
Accept:application/json;charset=UTF-8
Content-Type 用于描述本次请求的body的内容是json格式,且编码为UTF-8;Accept 用于描述客户端希望返回的结果以json来组织,且UTF-8。Content-Type 用于描述request,而Accept用于描述reponse
HTTP响应也由四部分组成:状态行、响应头、空行、响应体
响应报文示例
HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,60ct2003 13:23:42 GMT
Content-Length:112
<html>
<body>响应体</body>
</html>
GET | POST |
---|---|
参数通过URL传递 | 参数放在请求体中 |
只能进行un编码 | 支持多种编码方式 |
请求会被浏览器主动缓存 | 手动设置 |
请求参数会被完整保留在浏览器历史记录里 | 参数不会被保留 |
产生一个TCP数据包(把请求头和请求体一并发出去) | 产生两个TCP数据包(先发送请求头,服务器响应100 continue,再发送请求体) |
具体解析可查阅 get和post区别 后端接收参数(全面)
服务端可以向证书颁发机构(CA)申请证书,以避免中间人攻击(防止证书被算改),证书包含三部分:证书内容、证书签名算法、签名
服务端把证书传输给浏览器,浏览器从证书里取公钥。证书可以证明该公钥对应本网站
数字签名的制作过程
浏览器验证过程
假定某客户机想获知域名为xxx.example.com主机的IP地址,域名解析的过程(共使用8个UDP报文)如下:
HTTP协议是无状态的,即每一次请求都是独立的。服务器和客户端的交互仅限于请求/响应过程, 结束之后便断开, 在下一次请求时, 服务器会认为新的客户端。为了维护他们之间的链接, 让服务器知道这是前一个用户发送的请求, 必须在一个地方保存客户端的信息。即需要用某种机制来识别具体的用户身份,用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie、Session。
Cookie: 通过在 客户端 记录的信息确定用户的身份。 某些网站为了辨别用户身份而存储在本地终端(Client Side)上的数据(通常经过加密)。cookie实际存储在本地计算机的硬盘里,其最大储存量一般只有4k(识别用户身份,记录历史)。
Session: 通过在 服务器端 记录的信息确定用户的身份。 Session底层其实就是基于 Cookie 来实现的
cookie 和 session的关系:
cookie就是由服务器发送给客户端的特殊信息,而这些信息以文本文件的方式存放在客户端,然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。说得更具体一点,当用户使用浏览器访问一个支持cookie的网站的时候,用户会提供包括用户名在内的个人信息并且提交至服务器;接着,服务器在客户端回传相应的超文本的同时也会发回这些个人信息,这些信息存储于HTTP响应头中。当客户浏览器接收来自服务器的响应之后,浏览器将信息存放在一个统一的位置。自此,客户端再向服务器发送请求的时候,都会把相应的cookie存放在HTTP请求头,再次发回至服务器。服务器在接收到客户端浏览器的请求之后,就能够通过分析存放于请求头的cookie得到客户端持有的信息,从而动态生成与该客户端相对应的内容,网站的登录界面中"请记住我”这样的选项,就是通过cookie实现的
cookie工作流程
session原理:首先浏览器请求服务器访问web站点时,服务器首先会检查这个客户端请求是否已经包含了一个session标识,称为SESSIONED,如果已经包含了一个sessionid则说明以前为此客户端创建过session,服务器就按照sessionid把这个session检索出来使用;如果客户端请求不包含sessinonid,则服务器为此客户端创建一个session(在服务器端 Session数据会被存储在一个能够关联 Session ID 的数据结构中,例如内存、数据库或者文件存储等),并且生成一个与此session相关联的独一无二的sessionid存放到cookie中,这个sessionid将在本次响应中返回到客户端保存,这样在交互的过程中,浏览器每次请求时,都会带着这个sessionid,服务器根据这个sessionid就可以得到对应的session。以此来达到共享数据的目的,session不会随着浏览器的关闭而死亡,而是等待超时时间。
Cookie | Session | |
---|---|---|
作用范围 | 保存在客户端 | 保存在服务器端 |
隐私策略 | 容易被窃取 | 安全性相对要高 |
有效期 | 可设置长时间保持,比如默认登陆功能 | 失效时间较短,客户端关闭或Session超时都会失败 |
存储大小 | 单个Cookie保存的数据不超过4K | Session存储没有上限,但出于对服务器性能考虑,不用存放过多数据,且需要设置删除机制 |
对称加密 | 非对称加密 | |
---|---|---|
密钥 | 通信双方使用相同密钥进行加密 | 需要生成两个密钥,公钥、私钥 |
安全性 | 密钥泄露会导致密文数据被破解 | 公钥公开,私钥私人保管 |
速度 | 加密速度快 | 计算量大,加密和解密都很慢 |
常见算法 | AES、 DES | RSA、DSA |
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。