HTTPHTTP 的15个常见知识点复习.docx
- 文档编号:9526291
- 上传时间:2023-02-05
- 格式:DOCX
- 页数:29
- 大小:1.12MB
HTTPHTTP 的15个常见知识点复习.docx
《HTTPHTTP 的15个常见知识点复习.docx》由会员分享,可在线阅读,更多相关《HTTPHTTP 的15个常见知识点复习.docx(29页珍藏版)》请在冰豆网上搜索。
HTTPHTTP的15个常见知识点复习
一.简述浏览器输入URL地址后发生的事情
1.1描述
1.浏览器向DNS服务器查找输入URL对应的IP地址。
2.NS服务器返回网站的IP地址。
3.浏览器根据IP地址与目标web服务器在80端口上建立TCP连接。
4.浏览器获取请求页面的HTML代码。
5.浏览器在显示窗口内渲染HTML。
6.窗口关闭时,浏览器终止与服务器的连接。
1.2TCP知识点补充
参考文章:
《TCP三次握手和四次挥手协议》
建立TCP需要三次握手才能建立,而断开连接则需要四次握手。
整个过程如下图所示:
TCP三次握手:
所谓的三次握手,是指建立一个TCP连接时,需要客户端和服务器端总共发送三个包,三次握手的目的是连接服务器的指定端口,建立TCP连接,并同步连接双方的序列号和确认号并交换TCP窗口大小信息,在SOCKET编程中,客户端执行connect()时,将会触发三次握手:
TCP四次挥手:
TCP连接的拆除需要发送四个包,客户端或者服务器端均可主动发起挥手动作,在SOCKET编程中,任何一方执行close()即可产生挥手操作。
2.请介绍常见的HTTP状态码(至少五个)
状态码是由3位数组成,第一个数字定义了响应的类别,且有五种可能取值:
1xx:
指示信息–表示请求已接收,继续处理。
∙100客户必须继续发出请求
∙101客户要求服务器根据请求转换HTTP协议版本
2xx:
成功–表示请求已被成功接收、理解、接受。
∙200(成功)服务器已成功处理了请求。
通常,这表示服务器提供了请求的网页。
∙201(已创建)请求成功并且服务器创建了新的资源。
∙202(已接受)服务器已接受请求,但尚未处理。
3xx:
重定向–要完成请求必须进行更进一步的操作。
∙300(多种选择)针对请求,服务器可执行多种操作。
服务器可根据请求者(useragent)选择一项操作,或提供操作列表供请求者选择。
∙301(永久移动)请求的网页已永久移动到新位置。
服务器返回此响应(对GET或HEAD请求的响应)时,会自动将请求者转到新位置。
∙302(临时移动)服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。
4xx:
客户端错误–请求有语法错误或请求无法实现。
∙400(错误请求)服务器不理解请求的语法。
∙401(未授权)请求要求身份验证。
对于需要登录的网页,服务器可能返回此响应。
∙403(禁止)服务器拒绝请求。
5xx:
服务器端错误–服务器未能实现合法的请求。
∙500(服务器内部错误)服务器遇到错误,无法完成请求。
∙501(尚未实施)服务器不具备完成请求的功能。
例如,服务器无法识别请求方法时可能会返回此代码。
∙502(错误网关)服务器作为网关或代理,从上游服务器收到无效响应。
∙503(服务不可用)服务器目前无法使用(由于超载或停机维护)。
通常,这只是暂时状态。
∙504(网关超时)服务器作为网关或代理,但是没有及时从上游服务器收到请求。
∙505(HTTP版本不受支持)服务器不支持请求中所用的HTTP协议版本。
3.请介绍常见的HTTP头部(至少五个)
3.1HTTP头部
更多完整内容,可以查看 《HTTP响应头和请求头信息对照表》
首部字段名
说明
Accept
告诉服务器,客户端支持的数据类型。
Accept-Charset
告诉服务器,客户端采用的编码。
Accept-Encoding
告诉服务器,客户机支持的数据压缩格式。
Accept-Language
告诉服务器,客户机的语言环境。
Host
客户机通过这个头告诉服务器,想访问的主机名。
If-Modified-Since
客户机通过这个头告诉服务器,资源的缓存时间。
Referer
客户机通过这个头告诉服务器,它是从哪个资源来访问服务器的。
(一般用于防盗链)
User-Agent
客户机通过这个头告诉服务器,客户机的软件环境。
Cookie
客户机通过这个头告诉服务器,可以向服务器带数据。
Connection
客户机通过这个头告诉服务器,请求完后是关闭还是保持链接。
Date
客户机通过这个头告诉服务器,客户机当前请求时间
3.2RequestHeader
参考文章:
《HTTP常用头部信息》
举例:
RequestHeader
描述
GET/sample.JspHTTP/1.1
请求行
Host:
www.uuid.online/
请求的目标域名和端口号
Origin:
http:
//localhost:
8081/
请求的来源域名和端口号(跨域请求时,浏览器会自动带上这个头信息)
Referer:
https:
/localhost:
8081/link?
query=xxxxx
请求资源的完整URI
User-Agent:
Mozilla/5.0(WindowsNT10.0;Win64;x64)AppleWebKit/537.36(KHTML,likeGecko)Chrome/67.0.3396.99Safari/537.36
浏览器信息
Cookie:
BAIDUID=FA89F036:
FG=1;BD_HOME=1;sugstore=0
当前域名下的Cookie
Accept:
text/html,image/apng
代表客户端希望接受的数据类型是html或者是png图片类型
Accept-Encoding:
gzip,deflate
代表客户端能支持gzip和deflate格式的压缩
Accept-Language:
zh-CN,zh;q=0.9
代表客户端可以支持语言zh-CN或者zh(值得一提的是q(0~1)是优先级权重的意思,不写默认为1,这里zh-CN是1,zh是0.9)
Connection:
keep-alive
告诉服务器,客户端需要的tcp连接是一个长连接
3.3ResponseHeader
参考文章:
《HTTP常用头部信息》
举例:
|ResponseHeader|描述|
|---|---|
|HTTP/1.1200OK|响应状态行|
|Date:
Mon,30Jul201802:
50:
55GMT|服务端发送资源时的服务器时间|
|Expires:
Wed,31Dec196923:
59:
59GMT|较过时的一种验证缓存的方式,与浏览器(客户端)的时间比较,超过这个时间就不用缓存(不和服务器进行验证),适合版本比较稳定的网页|
|Cache-Control:
no-cache|现在最多使用的控制缓存的方式,会和服务器进行缓存验|证,具体见博文“Cache-Control”
|etag:
"fb8ba2f80b1d324bb997cbe188f28187-ssl-df"|一般是Nginx静态服务器发来的静态文件签名,浏览在没有“Disabledcache”情况下,接收到etag后,同一个url第二次请求就会自动带上“If-None-Match”|
|Last-Modified:
Fri,27Jul201811:
04:
55GMT|服务器发来的当前资源最后一次修改的时间,下次请求时,如果服务器上当前资源的修改时间大于这个时间,就返回新的资源内容|
|Content-Type:
text/html;charset=utf-8|如果返回是流式的数据,我们就必须告诉浏览器这个头,不然浏览器会下载这个页面,同时告诉浏览器是utf8编码,否则可能出现乱码|
|Content-Encoding:
gzip|告诉客户端,应该采用gzip对资源进行解码|
|Connection:
keep-alive|告诉客户端服务器的tcp连接也是一个长连接|
4.请列举常用的HTTP方法,并介绍GET与POST请求之间的区别
4.1HTTPRequestMethod
参考文章:
《HTTP请求方法对照表》
根据HTTP标准,HTTP请求可以使用多种请求方法。
HTTP1.0定义了三种请求方法:
GET,POST和HEAD方法。
HTTP/1.1新增了五种请求方法:
OPTIONS,PUT,DELETE,TRACE和CONNECT方法。
序号
方法
描述
1
GET
请求指定的页面信息,并返回实体主体。
2
HEAD
类似于get请求,只不过返回的响应中没有具体的内容,用于获取报头
3
POST
向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。
数据被包含在请求体中。
POST请求可能会导致新的资源的建立和/或已有资源的修改。
4
PUT
从客户端向服务器传送的数据取代指定的文档的内容。
5
DELETE
请求服务器删除指定的页面。
6
CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
7
OPTIONS
允许客户端查看服务器的性能。
8
TRACE
回显服务器收到的请求,主要用于测试或诊断。
9
PATCH
实体中包含一个表,表中说明与该URI所表示的原内容的区别。
10
MOVE
请求服务器将指定的页面移至另一个网络地址。
11
COPY
请求服务器将指定的页面拷贝至另一个网络地址。
12
LINK
请求服务器建立链接关系。
13
UNLINK
断开链接关系。
14
WRAPPED
允许客户端发送经过封装的请求。
15
Extension-mothed
在不改动协议的前提下,可增加另外的方法。
4.2GET与POST请求之间的区别
区别内容
GET
POST
点击返回/刷新按钮
没有影响
数据会重新发送(浏览器将会提示“数据被重新提交”)
添加书签
可以
不可以
缓存
可以
不可以
编码类型(Encodingtype)
application/x-www-form-rulencoded
application/x-www-form-rulencoded or multipart/form-data 请为二进制数据使用 multipart 编码
历史记录
有
没有
长度限制
有
没有
数据类型限制
只允许ASCLll字符类型
没有限制,允许二进制数据
安全性
查询字符串会显示在地址栏的URL上,不安全,请不要使用GET请求提交敏感数据
因为数据不会显示在地址栏中,也不会缓存下来或保存在浏览记录中,所以POST请求比GET请求安全,但也不是最安全的方式,如需要传送敏感数据,请使用数据加密。
可见性
查询字符串在地址栏的URL中可见
查询字符串在地址栏的URL中不可见
5.请分别介绍Cookie和Session的作用及它们之间的区别
参考文章:
《3分钟搞懂Cookie与Session》
5.1Cookie简单介绍
Cookie是存储在用户本地计算机上,用于保存一些用户操作的历史信息,当用户再次访问我们的服务器的时候,浏览器通过HTTP协议,将他们本地的Cookie内容也发到咱们服务器上,从而完成验证。
∙Cookie 是存储在浏览器客户的一小片数据;
∙Cookie 可以同时被前台与后台操作;
∙Cookie 可以跨页面存取;
∙Cookie 是不可以跨服务器访问的;
∙Cookie 有限制;每个浏览器存储的个数不能超过300个,每个服务器不能超过20个,数据量不能超过4K;
∙Cookie 是有生命周期的,默认与浏览器相同,如果进程退出,cookie会被销毁
5.2Session
Session存储在我们的服务器上,就是在我们的服务器上保存用户的操作信息。
当用户访问我们的网站时,我们的服务器会成一个 SessionID,然后把 SessionID 存储起来,再把这个 SessionID 发给我们的用户,用户再次访问我们的服务器的时候,拿着这个 SessionID就 能验证了,当这个ID能与我们服务器上存储的ID对应起来时,我们就可以认为是自己人。
∙seesion 数据存储在服务器端;
∙每一个会话分配一个单独的 session_id;
∙该 session_id 通过 cookie 传送到前台,默认的 session_id 名称是PHPSESSIONID;
∙前台只能看到 Session 的 ID,而不能修改 Session 值;
∙使用 Session 之前需要先开启会话;
∙Session 存储在 Session 数组 $_SESSION ;
∙Session 存储方式比较安全,但是如果 Session 数量过多,会导致服务器性能下降;
5.3两者区别
Cookie
session
定义
浏览器保存用户信息的文件,存储的数量和字符数都有限制
服务器把sessionID 和用户信息、用户操作,记录在服务器上,这些记录就称为session
相同点
都是为了存储用户相关的信息
存储
客户端
服务器
安全性
安全性不高,任何人都能直接查看
安全性高
5.4两者结合使用
∙存储在服务端:
通过 cookie 存储一个 session_id ,然后具体的数据则是保存在 session 中。
如果用户已经登录,则服务器会在 cookie 中保存一个 session_id ,下次再次请求的时候,会把该 session_id 携带上来,服务器根据 session_id 在 session 库中获取用户的 session 数据。
就能知道该用户到底是谁,以及之前保存的一些状态信息。
这种专业术语叫做 serversidesession 。
∙将 session 数据加密,然后存储在 cookie 中。
这种专业术语叫做 clientsidesession 。
6.请介绍HTTP请求报文与响应报文格式
6.1请求报文
请求报文由请求行、请求头部和请求正文组成:
∙请求行
格式为:
请求方法+空格+URL+空格+协议版本+回车符+换行符
例如:
GET HTTP/1.1
常见的请求方法有:
GET,HEAD,PUT,POST,TRACE,OPTIONS,DELETE以及扩展方法。
∙请求头部
格式为:
头部字段名+冒号(:
)+值+回车符+换行符
请求头部为请求报文添加了一些附加信息,由“名/值”对组成,每行一对,名和值之间使用冒号分隔。
并且,在请求头部的最后会有一个空行,表示请求头部结束,这一行必不可少。
典型的请求头部有:
请求头部
说明
Host
接受请求的服务器地址,可以是IP:
端口号,也可以是域名
User-Agent
发送请求的应用程序名称
Connection
指定与连接相关的属性,如Connection:
Keep-Alive
Accept-Charset
通知服务端可以发送的编码格式
Accept-Encoding
通知服务端可以发送的数据压缩格式
Accept-Language
通知服务端可以发送的语言
∙请求正文
一般使用在 POST 方法中, GET 方法不存在请求正文。
POST 方法适用于需要客户填写表单的场合。
与请求数据相关的最常使用的请求头是 Content-Type 和 Content-Length 。
6.2响应报文
响应报文由状态行、响应头部和响应正文组成:
∙状态行
格式为:
协议版本+空格+状态码+空格+状态码描述+回车符+换行符
状态码划分:
100〜199的状态码是HTTP/1.1向协议中引入了信息性状态码;
200〜299的状态码表示成功;
300〜399的状态码指资源重定向;
400〜499的状态码指客户端请求出错;
500〜599的状态码指服务端出错;
常见的状态码:
状态码
说明
200
响应成功
302
跳转,跳转地址通过响应头中的位置属性指定(JSP中Forward和Redirect之间的区别)
400
客户端请求有语法错误,不能被服务器识别
403
服务器接收到请求,但是拒绝提供服务(认证失败)
404
请求资源不存在
500
服务器内部错误
∙响应头部
格式为:
头部字段名+冒号(:
)+值+回车符+换行符
常见响应头部:
响应头部
说明
Server
服务器应用程序软件的名称和版本
Content-Type
响应正文的类型(是图片还是二进制字符串)
Content-Length
响应正文长度
Content-Charset
响应正文使用的编码
Content-Encoding
响应正文使用的数据压缩格式
Content-Language
响应正文使用的语言
7.HTTP/1.1有什么优缺点
参考文章:
《HTTP/1.0HTTP/1.1HTTP/2.0主要特性对比》
对于 HTTP/1.1 ,不仅继承了 HTTP1.0 简单的特点,还克服了诸多 HTTP1.0 性能上的问题。
7.1HTTP/1.1优点
1.增加持久性连接
也就是多个请求和响应可以利用同一个TCP连接,而不是每一次请求响应都要新建一个TCP连接,减少了建立和关闭连接的消耗和延迟。
Connection:
keep-alive
1.增加管道机制
增加了管道机制,请求可以同时发出,但是响应必须按照请求发出的顺序依次返回,性能在一定程度上得到了改善。
1.分块传输
在HTTP/1.1版本中,可以不必等待数据完全处理完毕再返回,服务器产生部分数据,那么就发送部分数据,很明此种方式更加优秀一些,可以节省很多等待时间。
1.增加 host 字段
使得一个服务器能够用来创建多个Web站点。
1.错误提示
HTTP/1.1引入了一个 Warning 头域,增加对错误或警告信息的描述,此外,在HTTP/1.1中新增了24个状态响应码(100,101,203,205,206,301,305…)。
1.带宽优化
HTTP/1.1中在请求消息中引入了 range 头域,它允许只请求资源的某个部分。
在响应消息中 Content-Range 头域声明了返回的这部分对象的偏移值和长度。
如果服务器相应地返回了对象所请求范围的内容,则响应码为 206(PartialContent) ,它可以防止 Cache 将响应误以为是完整的一个对象,HTTP/1.1加入了一个新的状态码 100(Continue)。
客户端事先发送一个只带头域的请求,如果服务器因为权限拒绝了请求,就回送响应码 401(Unauthorized);如果服务器接收此请求就回送响应码 100 ,客户端就可以继续发送带实体的完整请求了。
注意,HTTP/1.0的客户端不支持100响应码。
但可以让客户端在请求消息中加入 Expect 头域,并将它的值设置为 100-continue。
7.2HTTP/1.1缺点
1.队头阻塞
此版本的网络延迟问题主要由于队头堵塞导致,虽然通过持久性连接得到改善,但是每一个请求的响应依然需要按照顺序排队,如果前面的响应处理较为耗费时间,那么同样非常耗费性能。
1.技术不成熟
还有此版本虽然引进了管道机制,但是当前存在诸多问题,且默认处于关闭状态。
1.浪费资源
http/1.1请求会携带大量冗余的头信息,浪费了很多宽带资源。
8.相比HTTP/1.1,HTTP/2.0有哪些新特性
参考文章:
《HTTP1.0HTTP/1.1HTTP2.0主要特性对比》
∙二进制分帧
在应用层(HTTP/2.0)和传输层(TCPorUDP)之间增加一个二进制分帧层,从而突破HTTP1.1的性能限制,改进传输性能,实现低延迟和高吞吐量。
可见,虽然HTTP/2.0的协议和HTTP1.x协议之间的规范完全不同了,但是实际上HTTP/2.0并没有改变HTTP1.x的语义。
简单来说,HTTP/2.0只是把原来HTTP1.x的 header 和 body 部分用 frame 重新封装了一层而已。
∙多路复用(连接共享)
允许同时通过单一的HTTP/2连接发起多重的请求-响应消息,这个强大的功能则是基于“二进制分帧”的特性。
从图中可见,所有的HTTP/2.0通信都在一个TCP连接上完成,这个连接可以承载任意数量的双向数据流。
每个数据流以消息的形式发送,而消息由一或多个帧组成。
这些帧可以乱序发送,然后再根据每个帧头部的流标识符(streamid)重新组装。
∙首部压缩
HTTP1.1不支持 header 数据的压缩,HTTP/2.0使用 HPACK 算法对 header 的数据进行压缩,这样数据体积小了,在网络上传输就会更快。
高效的压缩算法可以很大的压缩 header ,减少发送包的数量从而降低延迟。
∙服务器推送
在HTTP/2中,服务器可以对客户端的一个请求发送多个响应,即服务器可以额外的向客户端推送资源,而无需客户端明确的请求。
9.请简述HTTPS工作原理
9.1HTTPS简介
参考文章:
《深入浅出讲解HTTPS工作原理》
HTTPS并非是应用层的一种新协议。
只是HTTP通信接口部分用SSL(SecureSocketLayer)和TLS(TransportLayerSecurity)协议代替而已。
通常,HTTP直接和TCP通信。
当使用SSL时,则演变成先和SSL通信,再由SSL和TCP通信了。
简言之,所谓HTTPS,其实就是身披SSL协议这层外壳的HTTP。
在采用SSL后,HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。
也就是说HTTP加上加密处理和认证以及完整性保护后即是HTTPS。
HTTPS协议的主要功能基本都依赖于TLS/SSL协议,TLS/SSL的功能实现主要依赖于三类基本算法:
散列函数 、对称加密和非对称加密,其利用非对称加密实现身份认证和密钥协商,对称加密算法采用协商的密钥对数据加密,基于散列函数验证信息的完整性。
9.2HTTPS工作原理
HTTPS其实是有两部分组成:
HTTP + SSL/TLS,也就是在HTTP上又加了一层处理加密信息的模块。
服务端和客户端的信息传输都会通过TLS进行加密,所以传输的数据都是加密后的数据。
1.客户端发起HTTPS请求
浏览器里面输入一个HTTPS网址,然后连接到服务端的443端口上。
注意这个过程中客户端会发送一个密文族给服务端,密文族是浏览器所支持的加密算法的清单。
1.服务端配置
采用HTTPS协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请。
区别就是自己颁发的证书需要客户端验证通过才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面。
这套证书其实就是一对公钥和私钥,可以这
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- HTTPHTTP 的15个常见知识点复习 15 常见 知识点 复习