HTTP、HTTPS

HTTP

  • HTTP请求格式


    image.png
  1. 请求方法: 9种
    GET:向指定的资源发出请求
    POST:向指定资源提交数据进行处理请求(例如提交表单或上传文件)
    HEAD:向服务器索要与GET请求相一致的相应,只不过相应体将不会被返回。用于测试超链接的有效性,是否可以访问、以及最近是否更新等信息。
    OPTIONS:返回服务器针对特定资源所支持的HTTP请求方法
    PUT:向指定资源位置上传最新内容
    DELETE:请求服务器删除Request-URI所标识的资源
    TRACE:回显服务器收到的请求,主要用于测试或诊断
    CONNECT:HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器
    PATCH:用来将局部修改应用于某个资源。
  2. 请求头常用字段
Host:www.jianshu.com
Connection: keep-alive
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9

Host用于指定被请求资源的Internet主机和端口号,从HTTP URL中提取出来的。默认端口号80,若指定端口号也可以。
Connection:keep-alive和close两个值。keep-alive解决效率低,可使客户端到服务端的连接持续有效。
Accept:浏览器端可接收MIME类型。/表示浏览器可以处理所有类型。
Cache-Control:指定请求和响应遵循的缓存机制
Accept-Encoding:浏览器声明自己可接收的编码方法
User-Agent用于告诉HTTP服务器,客户端使用的操作系统和浏览器的名称和版本。
If-Modified-Since:把浏览器端缓存页面的最后修改时间发送给服务器。
Cookie: 将cookie的值发送给http服务器
Referer: 包含一个URL,用户从该URL代表的页面出发访问当前请求的页面,告诉服务器从哪个页面链接过来的。CSRF攻击(CSRF攻击传来的请求,Refer而字段会是包含恶意网址的地址),gsid漏洞(通过referer把当前页面的url主动发送到攻击者服务器)。

  1. HTTP回应报文
  • 相应报文状态码
    返回码由3位数字组成,第一个数字定义响应类别,且有五种可能取值
    image.png
  • 100 Continue
  • 200:OK 表明客户端请求成功
  • 204: No Content :请求已经成功处理,但是返回的响应报文不包含实体
    的主体部分。一般在只需要从客户端往服务器发送信息,而不需要返回数据时使用。
  • 206 Partial Content 成功执行一个范围请求
  • 301 Permanently Moved 永久性转移,搜索引擎在抓取新内容的同时也将旧网址替换为重定向后的网址。场景:域名跳转。
  • 302 Temporarity Moved 暂时性转移,搜索引擎会抓取新内容而保存旧网址。场景:未登陆的用户访问用户中心重定向到登陆页面,搜索引擎会抓取新的内容而保留旧的地址 会发生网络劫持现象
    ps:
  1. 重定向原因
    a 网站调整
    b 网页被移到新地址
    c 网页扩展名改变(如应用需要把.php改成.html)
  2. 什么时候进行301或302跳转
    a 域名到期不想续费或想换个域名
    b 在搜索引擎的搜索结果中出现不带www的域名,而带www的域名却没有收录。这个时候可以通过301重定向告诉搜索引擎目标域名是哪一个
    c 空间服务器不稳定
    d 浏览器跟踪重定向地址
  • 303 see other 请求的资源存在着另一个URI,客户端应使用GET方法定向获取请求的资源

  • 304 Not Modified :服务器内容没有更新,可以直接读取浏览器缓存。

  • 307 Temporary Redirect 临时重定向。和302含义一样

  • 400 Bad Request :客户端请求报文中存在语法错误。不能被服务器所理解

  • 401 Unauthorized :请求未经授权,这个请求必须和 WWW-Authenticate 报文域一起使用

  • 403 Forbidden 服务器收到请求,但是拒绝提供服务

  • 404 Not Found 请求资源不存在,比如输入了错误的 url

  • 500 Internet Server Error 服务器发生了不可描述的错误

  • 502 Bad Gateway 是一种HTTP协议的服务器端错误状态代码,它表示作为网关或代理角色的服务器,从上游服务器(如tomcat、php-fpm)中接收到的响应是无效的

  • 503 Server Unavailable 服务器当前不能处理客户端请求,一段时间后可能回复正常

HTTP版本之间的区别

  1. HTTP/1.1 的首部带有大量信息,而且每次都要重复发送。
  2. HTTP/2.0 要求客户端和服务器同时维护和更新一个包含之前见过的首部字段表,从而避免了重复传输。
  3. 不仅如此,HTTP/2.0 也使用 Huffman 编码对首部字段进行压缩。
  • HTTP1.0和HTTP1.1的区别:
  1. 缓存处理
    在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准。
    HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
  2. 带宽优化及网络连接的使用
    HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能。HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。
  3. 错误通知的管理
    在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
  4. Host头处理
    在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。
    但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。
    HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。
  5. 长连接
    HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,在HTTP1.1中默认开启Connection: keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
  • HTTP1.1和HTTP2.0的区别
  1. 新的二进制格式(Binary Format)
    HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷,文本的表现形式有多样性,要做到健壮性考虑的场景必然很多,二进制则不同,只认0和1的组合。
    基于这种考虑HTTP2.0的协议解析决定采用二进制格式,实现方便且健壮。
    2) 多路复用(MultiPlexing),即连接共享,即每一个request都是是用作连接共享机制的。一个request对应一个id,这样一个连接上可以有多个request,每个连接的request可以随机的混杂在一起,接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

3) header压缩
如上文中所言,对前面提到过HTTP1.x的header带有大量信息,而且每次都要重复发送。
HTTP2.0使用encoder来减少需要传输的header大小,通讯双方各自cache一份header fields表,既避免了重复header的传输,又减小了需要传输的大小。
4) 服务端推送(server push),同SPDY一样,HTTP2.0也具有server push功能

  • 长连接与短连接
  1. 当浏览器访问一个包含多张图片的 HTML 页面时,除了请求访问 HTML 页面资源,还会请求图片资源。如果每进行一次 HTTP 通信就要新建一个 TCP 连接,那么开销会很大。

  2. 长连接只需要建立一次 TCP 连接就能进行多次 HTTP 通信。

  3. 从 HTTP/1.1 开始默认是长连接的,如果要断开连接,需要由客户端或者服务器端提出断开,使用 Connection : close;

  4. 在 HTTP/1.1 之前默认是短连接的,如果需要使用长连接,则使用 Connection : Keep-Alive

HTTPS

  • HTTPS的工作原理
image.png
  1. 客户端发起 HTTPS 请求
    用户在浏览器里输入一个 https 网址,然后连接到 server 的 443 端口。
  2. 服务端的配置
    采用 HTTPS 协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请,区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面(startssl 就是个不错的选择,有 1 年的免费服务)。

这套证书其实就是一对公钥和私钥,如果对公钥和私钥不太理解,可以想象成一把钥匙和一个锁头,只是全世界只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。

  1. 传送证书
    这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。

  2. 客户端解析证书
    这部分工作是有客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。
    如果证书没有问题,那么就生成一个随机值,然后用证书对该随机值进行加密,就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。

  3. 传送加密信息

这部分传送的是用证书加密后的随机值(随机数使用公钥进行加密(RSA加密),目的就是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了(RSA加密)。

  1. 服务端解密信息
    服务端用私钥解密后,得到了客户端传过来的随机值(私钥),然后把内容通过该值进行对称加密,所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。

  2. 传输加密后的信息

这部分信息是服务段用私钥加密后的信息,可以在客户端被还原。

  1. 客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容,整个过程第三方即使监听到了数据,也束手无策。

  • 加密方式
  1. 对称密钥加密
    对称秘钥加密解密使用同一秘钥
    优点: 运算速度快
    缺点: 无法安全地将秘钥传输给通信方
    常见: AES TEA
  2. 非对称秘钥加密

非对称密钥加密,又称公开密钥加密(Public-Key Encryption),加密和解密使用不同的密钥。
也就是秘钥成对出现(根据公钥无法推知私钥,根据私钥无法推知公钥),加密解密使用不用秘钥(公钥加密需要私钥解密,私钥加密需要公钥解密) 公开密钥所有人都可以获得,通信发送方获得接收方的公开密钥之后,就可以使用公开密钥进行加密,接收方收到通信内容后使用私有密钥解密。*
优点:安全*
缺点:运算速度慢*
常见的有:RSA ECC
对称密钥密码体系
消息发送方和接收方都使用相同的密钥,该密钥必须保密。发送方用该密钥对待发消息进行加密,然后将消息传输至接收方,接收方再用相同的密钥对收到的消息进行解密。

K 密钥 M待加密消息 E加密后消息
decrypt()解密函数
M=decrypt(K,E)=decrypt(K,encrypt(K,M)) 

非对称密钥密码体系
使用两个密钥:一个公共密钥PK和一个私有密钥SK。这两个密钥在数学上使相关的,并不能由公钥计算出对应的私钥,同样不能由私钥计算出对应的公钥。

  • HTTPS 采用的加密方式
    HTTPS 采用混合的加密机制
    使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性。
    之后使用对称密钥加密进行通信来保证通信过程的效率。
    图片所在博客很不错,值得一看
加密的所有算法

HTTP和HTTPS区别

image.png
  • HTTPS 协议需要到数字证书认证机构(CA, Certificate Authority )申请证书,一般免费证书很少,需要交费
  • HTTP 是超文本传输协议,信息是明文传输,HTTPS 则是具有安全性的 ssl 加密传输协议
  • HTTP 和 HTTPS 使用完全不同的连接方式,用的端口也不一样,前者是 80,后者是 443
  • HTTP 的连接很简单,是无状态的;HTTPS 协议是由 ssl+HTTP 协议构建的可进行加密传输、身份认证的网络协议,比 HTTP 协议安全
  • 目前,HTTPS 的应用比 HTTP 少,是因为 HTTPS 比较耗性能,对于安全性没那么高要求的应用来说,用 HTTP 就已经够了

session和cookie的区别和联系

  • cookie
    cookie是浏览器的一种缓存机制,用于维持客户端与服务器之间的会话。cookie将会话保存在客户端
    以常见的登陆案例讲解cookie的使用过程:
  1. 首先用户在客户端浏览器向服务器发起登陆请求
  2. 登陆成功后,服务端会把登陆的用户信息设置 cookie 中,返回给客户端浏览器
  3. 客户端浏览器接收到 cookie 请求后,会把 cookie 保存到本地(可能是内存,也可能是磁盘,看具体使用情况而定)
  4. 以后再次访问该 web 应用时,客户端浏览器就会把本地的 cookie 带上,这样服务端就能根据 cookie 获得用户信息了
  • session
    session是一种维持客户端与服务器端会话的机制,但是与cookie把会话信息保存在客户端本地不同,session把会话保留在浏览器端
    同样以登陆案例讲解session的使用过程:
  1. 首先用户在客户端浏览器发起登陆请求
  2. 登陆成功后,服务端会把用户信息保存在服务端,并返回一个唯一的 session 标识给客户端浏览器。
  3. 客户端浏览器会把这个唯一的 session 标识保存在起来
  4. 以后再次访问 web 应用时,客户端浏览器会把这个唯一的 session 标识带上,这样服务端就能根据这个唯一标识找到用户信息。
  • 区别
  1. cookie 是浏览器提供的一种缓存机制,它可以用于维持客户端与服务端之间的会话
  2. session 指的是维持客户端与服务端会话的一种机制,它可以通过 cookie 实现,也可以通过别的手段实现。
  3. 如果用 cookie 实现会话,那么会话会保存在客户端浏览器中
  4. 而 session 机制提供的会话是保存在服务端的。
  5. 持久连接是为了用来保证当来自同一个用户的请求时能够定位到同一台服务器,目的是为了会话保持,而通常使用的会话保持技术手段就是cookie与session。
    cookie与session简述
       在Web服务通信中,HTTP本身是无状态协议,不能标识用户来源,当用户在访问A网页,再从A网页访问其他资源跳转到了B网页,这对于服务器来说又是一个新的请求,之前的登陆信息都没有了,怎么办?为了记录用户的身份信息,开发者在浏览器和服务器之间提供了cookie和session技术,简单说来在你浏览网页时候,服务器建立session用于保存你的身份信息,并将与之对应的cookie信息发送给浏览器,浏览器保存cookie,当你再次浏览该网页时候,服务器检查你的浏览器中的cookie并获取与之对应的session数据,这样一来你上次浏览网页的数据依然存在。

输入网址到显示的过程输入网址到显示的过程

  1. 在客户端浏览器中输入网址URL
  2. 发送到DNS域名服务器获得域名对应的web服务器的IP地址
  3. 客户端浏览器与web服务器建立TCP(传输控制协议)连接
  4. 客户端浏览器向对应IP地址的web服务器发送相应的http或https请求
  5. web服务器响应请求,返回指定的URL数据或错误信息;如果设定重定向,则重定向到新的URL地址
  6. 客户端浏览器下载数据,解析HTML源文件,解析后,在浏览器中显示基础页面。
详细分析这个过程
  • 从客户端浏览器中输入网址URL
  • 浏览器查找域名对应的IP地址
  1. 首先查看本地硬盘的hosts文件,其中是否有和这个域名对应的规则,如果有的话直接使用hosts文件里面的ip地址。
  2. 如果本地的hosts文件没有找到对应的ip地址,浏览器会发出一个DNS请求到本地DNS服务器。本地DNS服务器一般是你的网络接入服务器商提供,比如中国电信,移动等。
  3. 查询你输入网址的DNS请求到达本地DNS服务器之后,本地DNS服务器会首先查询它的缓存记录,如果缓存中有此条记录,就可以直接返回结果,次过程是递归的方式进行查询。如果没有,本地DNS服务器还要向DNS根服务器进行查询。
  4. 根DNS服务器没有记录具体的域名和IP地址的对应关系,而是告诉本地DNS服务器,你可以到域服务器上去继续查询,并给出域服务器的地址。这个过程是迭代的过程。
  5. 本地DNS服务器继续向域服务器发出请求,在本例中,请求的对象是.com域服务器。.com域服务器收到请求之后,也不会直接返回域名和IP地址的对应关系,而是告诉本地DNS服务器,你的域名的解析服务器的地址。
  6. 最后,本地DNS服务器向域名的解析服务器发出请求,这时就能收到一个域名和IP地址对应关系,本地DNS服务器不仅要把IP地址返回给用户电脑,还要把这个对应关系保存在缓存中,以备下次别的用户查询时,可以直接返回结果,加快网络访问。
    图片所在博客很不错
    DNS过程
  • 浏览器向web服务器发送一个http请求
    拿到域名对应的IP地址之后,浏览器会以一个随机端口(1024<端口号<65535)向服务器的web程序80端口发起TCP连接请求。
    建立TCP连接后,发起http请求。一个典型的http request header一般需要包括请求的方法如get或post等。客户端向服务器发起http请求会有一些请求信息,包括三部分:
  1. 请求方法URI 协议/版本
  2. 请求头(Request Header)
  3. 请求正文
GET/sample.jsp  HTTP/1.1   //方法URI协议/版本
//请求头
 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=zhihu&password=abc

扩展:三次握手、四次挥手、重定向

  • 服务器处理请求
    http请求发送到服务器。即后端从固定的端口接收到TCP报文,对TCP连接进行处理,对HTTP协议进行解析,并按照报文格式进一步封装成http request对象,供上层使用。
  • 服务器返回一个HTTP响应
    HTTP响应由3部分构成,分别为:
  1. 状态行
  2. 响应头
  3. 响应正文
HTTP/1.1 200 OK   //状态行:协议版本加状态码
//响应头
Date: Sat, 31 Dec 2005 23:59:59 GMT   
Content-Type: text/html;charset=ISO-8859-1   Content-Length: 122   
//响应正文
<html>   
<head>   
<title>http</title>   
</head>   
<body>   
<!-- body goes here -->   
</body>   
</html>
  • 浏览器显示HTML

  • SQL注入

  1. 判断有无注入点 and 1=1/ and 1 =2
  2. 猜表(表名为admin、user、pass等)
  3. 猜字段等等
    参考1
    参考2
    参考3
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,204评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,091评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,548评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,657评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,689评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,554评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,302评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,216评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,661评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,851评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,977评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,697评论 5 347
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,306评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,898评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,019评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,138评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,927评论 2 355