HTTP、HTTPS相关知识

HTTP


HTTP是一种应用层的超文本传输协议,这就意味着它能够传输包括文字、图片、音频、视频等格式的内容。

HTTP从1.1之后开始支持长连接,但长连接并不意味着永久连接。

HTTP是无状态的,同一个客户端对服务端多次请求,服务端无法识别是否是同一个用户,因此引入了Cookie和Session技术。

HTTP报文

HTTP报文分为请求报文和响应报文,每一种报文均由三部分组成,它们分别是请求行、请求头、请求体响应行、响应头、响应体

请求行包含HTTP版本、方法、请求URL三方面信息;请求头包含接收数据类型、完整URL地址、编码类型、设备信息、长连接、Cookie等;请求体包含真正想传输给服务器的内容,请求体不是必须的。

响应行包含HTTP版本、响应码、响应信息三方面信息;响应头包含的内容和请求头类似,不过Cookie字段变为了Set-Cookie;响应体则是服务端返回给数据内容

请求方法

HTTP请求方法除了常用的GET、POST请求以外,还包括HEAD、PUT、DELETE、OPTIONS四种请求方式。

GET和POST的区别在于,GET是安全的、幂等的、可缓存的,POST是非安全的、非幂等的、非缓存的

为什么这么说呢?因为按照标准的GET和POST设计思路,GET请求不应该引起服务端数据的变化,由于服务端数据不变,因此相同参数的GET请求每次返回的结果都应该是一样的,针对这个特性,我们就可以把这部分数据缓存起来使用。

另外,GET请求一般参数不超过2048个字符,POST请求则没有限制。

响应码

HTTP响应码一般包含1xx、2xx、3xx、4xx、5xx。当http请求只发送请求头不发送请求体的时候,如果服务器认为客户端可以授权连接,则会返回100,否则返回401,然后客户端可以接着发送请求体,以达到节约带宽的目的;200表示响应结果正常;301、302表示页面需要重定向;404表示页面不存在,403表示页面拒绝访问;500通常是服务器出了问题。

长连接

通过TCP协议与服务器建立连接时,每一次的请求都需要与服务器建立连接之后才能进行数据交换,这给网络请求带来了时间上的浪费。因此HTTP1.1之后增加了长连接的属性,在一次连接后,可以多次进行数据交互,直到时间过期或交互数超额才断开连接

通过设定请求头的Connection:kepp-alive; time-out:20; max:5属性,我们可以与服务器建立长连接。其中time-out是指20秒后断开连接,max是指这20秒内最多进行5次数据交互。

Cookie和Session的区别

Cookie和Session其实就是一个JSON字符串,它们都是用来记录用户状态,他们的区别在于Cookie保存在客户端,Session保存在服务端

服务端收到客户端传输的账号密码等信息后,会为该用户生成一个SessionId,并通过响应头Set-Cookie方式将SessionId和其他一些辅助参数传给客户端,客户端将这部分信息保存在本地,并且每次请求时都将此信息设置在请求头Cookie中传输给服务器。

TCP和UDP


UDP

UDP是一种传输层的用户数据报协议,它的特点是无连接、尽最大努力交付、面向报文

无连接意味着它不需要事先与服务器建立连接,也就没有断开连接的操作。由于这个无连接的特性,因此它无法保证传输的数据能够准确的到达服务器(假设服务器刚好处于崩溃状态,数据就丢失了)。面向报文是指应用层给多少数据,它就传输多少数据,不会对数据进行拆分或合并传输。无连接和面向报文给UDP带来的好处就是传输的速度更快

UDP具备差错校验机制,不过笔者我不熟就不班门弄斧了。这里还有个复用、分用的概念,TCP也是如此。简单的说,复用就是指多个传输端口可以共用一个传输协议,分用则是指当接收到数据时,通过一个传输协议可以回传给多个传输端口。

TCP

TCP协议是一种挺复杂的传输协议,它是一种传输层的传输控制协议,它的特点是需要连接、可靠交付、面向字节流、流量控制、拥塞控制

首先,需要连接是指客户端在发起HTTP请求是,需要先跟服务端建立连接,建立连接的过程我们称之为三次握手

1. 客户端向服务端发送同步报文SYN
2. 服务端收到报文后向客户端发送同步确认报文SYN,ACK
3. 客户端再向服务端发送确认报文ACK

三次握手示意图

为什么要进行三次握手,而不是两次?
这主要是跟TCP的可靠性和超时重传机制有关,在第一次握手时可能因为网络拥塞导致服务器延迟收到,或者第二次握手时客户端延迟收到。此时客户端就会重新发送同步报文,当客户端重新发送同步报文后,如果收到了第一次发送的报文,就会直接丢弃,以第二次的为准。

建立连接后,客户端断就可以多次向服务请求数据,最后再断开连接,多次请求数据主要依赖HTTP的长连接属性。断开连接的过程我们称之为四次挥手

1. 客户端不需要在发送数据时会向服务端发送结束报文FIN。
2. 服务端收到后回复确认结束报文ACK,意思就是‘我知道你不再发数据了’。
3. 服务端不需要在发送数据时会向客户端发送结束报文FIN,ACK。
4. 客户端收到后回复确认结束报文ACK。
当双发都确认结束后,这条传输通道就关闭了。

这里面有个小概念是全双工通道,意思是通道的双发都可以主动向对方发消息。而不是两条通道。

四次挥手示意图

可靠交付面向字节流我们可以合起来理解,面向字节流的特性决定了TCP会通过自身的一套方式对应用层提交的数据进行拆分或合并,也就是说应用层一次性给10个字节,TCP并不一定一次性将这10个字节对外传输。数据被拆分或合并后,为了保证数据的准确性其传输必须是有序的,前一部分数据确认抵达后才会继续传输下一部分数据。如果其中因为网络问题触发了超时重传,那么重复的数据将被摒弃,因此TCP传输是不重复的。有序、准确、不重复决定了TCP是可靠交付。

流量控制涉及到一个叫滑动窗口的概念。数据发送时会进入发送缓冲区待命,每一次发送的数据量就是一个发送窗口。由于双发所处的网络环境、设备环境可能不一致,当一方发送数据过多时就会导致接收方缓冲区溢出,因此发送方的每一次发送窗口大小是由接收方动态决定的,这个机制就是所谓的流量控制。发送窗口是有编号的,并且是按序增大,假设接收方先接收到序号为3的数据,并未接收到1、2号数据,就会将序号为3的数据先放在数据缓存区,等待1、2号数据到达后才提交给应用层,所以我们说TCP传输是有序的

流量控制-滑动窗口示意图

拥塞控制主要方式是慢开始、拥塞避免。接收方会给发送方一个门限初始值,在达到门限值之前发送方每次发送的数据量呈指数增长,即1、2、4、8、16这样的方式,当达到门限值16后改为加法增长,17、18、19...当到达某个数值时,比如20,发现接收方的确认速度变慢了(可能因此网络拥塞等因素),就会将每次发送数据量重新从1、2、4...开始恢复。有一种变种控制方式快恢复、快重传是指遇到拥塞后,数据量不会重新从1开始,而是从拥塞值的一半开始(比如20的一半,10)。

拥塞控制示意图

DNS解析

DNS解析实际上是将域名映射为IP地址的一个过程,采用的是UDP+明文的方式进行传输。DNS主要通过递归查询迭代查询两种方式解析域名。

递归查询是一种层层向上的查询方式,由本地DNS > 根域DNS > 顶级DNS > 权限DNS向上查询,直到一方返回结果。

迭代查询则是本地DNS直接向各级DNS进行查询方式,各级DNS会告知本地DNS“A可能知道结果”,本地DNS直接去找“A”获取IP地址。

DNS解析转发是指DNS服务器为了减小压力,将DNS解析请求转发给了其他网络营运商(比如移动转发给电信),由该营运商提供解析结果。由于这种转发的方式,客户端可能会获得跟自身所处网络环境不一样的网络营运商的地址,就可能会出现请求响应慢的问题。

DNS劫持是指伪装的DNS服务器通过53端口截获了DNS解析请求,并返回给客户端虚假的IP地址。我们可以通过httpDNS的请求方式,即使用HTTP协议直接向DNS服务器的80端口发起GET请求,并将目标域名和自身的IP地址拼接在URL参数上。

HTTP2.0

HTTP1.x版本在通过一个TCP链接中多次发起请求,后发起的请求会被先发起的请求阻塞,也就是请求是串行的,必须等到前一个请求返回结果后才能接着处理下一个请求。针对这种现象,在请求数较多的情况下HTTP会建立多个TCP连接来获取数据,但是建立TCP链接需要经历握手与挥手流程,对时间和性能上也存在着一定的损耗。
2.0版本通过多路复用的方式解决了这个问题,同一个TCP连接通过轮询的方式来发送请求,即前一个请求在等待数据的过程中,会接着判断队列中是否有其他请求,如果有则直接发送下一个请求。
2.0版本具备头部压缩特性,会对HTTP请求头进行数据压缩,以达到更快的请求速度。
2.0版本采取了二进制格式传递数据,而非文本传输
2.0版本使得服务端在建立连接后,能够主动推送数据给客户端。

HTTPS


HTTP的数据传输采用的是明文方式,安全性无法得到保障,因此产生了SSL协议用于HTTP数据加密,我们也就称之为HTTPS。SSL是早期的协议,现在一般采用是TLS。
TLS/SSL同样也位于应用层,严格上来说是位于HTTP应用层之下,TCP传输层之上的一个中间层。
当一个HTTPS请求发送给服务器时,会经历以下几个握手流程:

1. 客户端将支持的加密算法、随机数A、TLS版本传输给服务端;
2. 服务端选择一套算法、随机数B、证书传输给客户端;
3. 客户端进行证书校验、产生一个预主秘钥C,通过证书中的公钥对秘钥进行加密;
4. 客户端将加密后的预主秘钥C发送给服务端,服务端通过私钥进行解密得到秘钥C;
5. 双发通过随机数A、随机数B、预主秘钥C组装成会话秘钥后,使用会话秘钥发送一次加密的握手消息,来验证会话秘钥是否有效。
6. 验证成功后开始数据交互。

TLS握手流程示意图

HTTPS首先采用证书中的公钥和秘钥进行非对称加密,由于秘钥存在服务端中,不会在网络中传递,这样可以确保会话秘钥不会在传输过程中被恶意截获。但非对称加密(公、私钥不同)的性能相对耗时,因此后续的数据交互均采用组装好的会话秘钥进行对称加密

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

推荐阅读更多精彩内容