阿里P6之十网络通信与协议

个人专题目录


10. 网络通信与协议

10.1 http和https的区别,https原理,http2.0与1.0的区别

HTTP和HTTPS的区别

HTTPS:是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP下加入SSL层,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。

HTTPS协议的主要作用可以分为两种:一种是建立一个信息安全通道,来保证数据传输的安全;另一种就是确认网站的真实性。

两者主要区别如下:

  • https协议需要到ca申请证书,一般免费证书较少,因而需要一定费用。
  • http是超文本传输协议,信息是明文传输,https则是具有安全性的ssl加密传输协议。
  • http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
  • http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。

HTTP/2采用二进制格式而非文本格式

HTTP/2是完全多路复用的,而非有序并阻塞的——只需一个连接即可实现并行

使用报头压缩,HTTP/2降低了开销

HTTP/2让服务器可以将响应主动“推送”到客户端缓存中

1.多路复用和二进制帧

HTTP 性能优化的关键并不在于高带宽,而是低延迟。TCP 连接会随着时间进行自我「调谐」,起初会限制连接的最大速度,如果数据成功传输,会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因,让原本就具有突发性和短时性的 HTTP 连接变的十分低效。

HTTP/2 通过让所有数据流共用同一个连接,可以更有效地使用 TCP 连接,让高带宽也能真正的服务于 HTTP 的性能提升。

2.首部压缩

在 HTTP/1 中,HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言,消息主体都会经过 gzip 压缩,或者本身传输的就是压缩过后的二进制文件(例如图片、音频),但状态行和头部却没有经过任何压缩,直接以纯文本传输。

头部压缩需要在支持 HTTP/2 的浏览器和服务端之间:

  • 维护一份相同的静态字典(Static Table),包含常见的头部名称,以及特别常见的头部名称与值的组合;
  • 维护一份相同的动态字典(Dynamic Table),可以动态的添加内容;
  • 支持基于静态哈夫曼码表的哈夫曼编码(Huffman Coding);

10.2 Http报文格式

Http请求报文格式:1.请求行 2.Http头 3.报文主体

请求行由三部分组成,分别是请求方法,请求地址,Http版本

Http头:有三种,分别为请求头(request header),普通头(General Header)和实体头(entity header)。Get方法没有实体头。

报文主体:只在POST方法请求中存在。

Http响应报文:1.状态行 2.Http头 3.返回内容

状态行:第一部分为Http版本,第二部分为响应状态码 第三部分为状态码的描述

其中第三部分为状态码的描述,信息类100-199 响应成功200-299 重定向类300-399 客户端错误400-499 服务器端错误500-599

常见的

100 continue 初始请求已接受,客户端应继续发送请求剩余部分
200 OK
202 Accepted 已接受,处理尚未完成 
301 永久重定向
302 临时重定向
400 Bad Request
401 Unauthorized
403 Forbidden 资源不可用
404 Not Found
500 Internal Server Error 服务器错误
502 Bad Gateway
503 Service Unavailable 服务器负载过重
504 Gateway Timeout 未能及时从远程服务器获得应答

Http头:响应头(Response Header),普通头(General Header)和实体头(Entity Header)

返回内容:即Http请求的信息,可以是HTML也可以是图片等等。

10.3 TCP连接建立和释放的过程

SYN置1和FIN的报文段要消耗一个序号。

客户端连接状态变迁:CLOSED -> 主动打开,发送SYN=1 -> SYN_SENT -> 收到服务器的SYN=1和ACK时,发送三次握手的最后一个ACK
-> ESTABLISHED -> 数据传送 -> 主动关闭 -> 发送FIN=1,等待确认ACK的到达 -> FIN_WAIT_1 -> 收到确认ACK后 -> FIN_WAIT_2
-> 收到服务器发送的FIN=1报文,响应,发送四次挥手的的最后一个确认ACK -> 进入TIME_WAIT状态
-> 经过2倍报文寿命,TCP删除连接记录 -> 回到CLOSED状态

客户端状态:CLOSED - SYN_SENT- ESTABLISHED - FIN_WAIT_1 - FIN_WAIT_2 - TIME_WAIT - CLOSED

服务器端连接状态变迁:CLOSED -> 被动打开 -> LISTEN -> 收到SYN=1的报文,发送SYN=1和确认ACK -> 进入SYN_RCVD -> 收到三次握手
的最后一个确认ACK -> ESTABLISHED -> 数据传送 -> 数据传送完毕,收到FIN=1 -> 发送确认ACK并进入CLOSED_WAIT -> 发送FIN=1给客户端 -> LAST_ACK
-> 收到客户端四次挥手的最后一个确认ACK -> 删除连接记录 -> 回到CLOSED状态

服务器端:CLOSED - LISTEN - SYN_RCVD - ESTABLISHED - CLOSED_WAIT - LAST_ACK - CLOSED

10.3.1 TCP的三次握手和四次挥手的过程

以客户端为例

连接建立(三次握手):首先Client端发送连接请求报文SYN并进入SYN_SENT状态,Server收到后发送ACK+SYN报文,并为这次连接分配资源。Client端接收到Server端的SYN+ACK后发送三次握手的最后一个ACK,并分配资源,连接建立。

连接释放(四次挥手):假设Client端发起断开连接请求,首先发送FIN=1,等待确认ACK的到达 -> FIN_WAIT_1 -> 收到Server端的确认ACK后时 -> FIN_WAIT_2
->收到服务器发送的FIN=1报文,响应,发送四次挥手的的最后一个确认ACK ->进入TIME_WAIT状态
-> 经过2倍报文寿命,TCP删除连接记录 -> 回到CLOSED状态

10.3.2 为什么连接建立是三次握手,而连接释放要四次挥手?

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

10.3.3 为什么TIME_WAIT状态需要2MSL(最大报文段生存时间)才能返回Closed状态?

这是因为虽然双方都同意关闭连接了,而且四次挥手的报文也都协调发送完毕。但是我们必须假想网络是不可靠的,无法保证最后发送的ACK报文一定被对方收到,因此处于LAST_ACK状态下的
Server端可能会因未收到ACK而重发FIN,所以TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

10.4 Post和Get的区别

  • 安全性上说:get的方式是把数据在地址栏中明文的形式发送,URL中可见,POST方式对用户是透明的,安全性更高。
  • 数据量说:Get传送的数据量较小,一般不能大于2KB,POST传送的数据量更大。
  • 适用范围说:查询用Get,数据添加、修改和删除建议Post
  • post请求的过程:
    • 浏览器请求tcp连接(第一次握手)
    • 服务器答应进行tcp连接(第二次握手)
    • 浏览器确认,并发送post请求头(第三次握手,这个报文比较小,所以http会在此时进行第一次数据发送)
    • 服务器返回100 Continue响应
    • 浏览器发送数据
    • 服务器返回200 OK响应
  • get请求的过程:
    • 浏览器请求tcp连接(第一次握手)
    • 服务器答应进行tcp连接(第二次握手)
    • 浏览器确认,并发送get请求头和数据(第三次握手,这个报文比较小,所以http会在此时进行第一次数据发送)
    • 服务器返回200 OK响应

10.5 Cookie 和 Session的区别

  1. cookie数据存放在客户的浏览器上,session数据放在服务器上。
  2. cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
    考虑到安全应当使用session。
  3. session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能
    考虑到减轻服务器性能方面,应当使用COOKIE。
  4. 单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。
  5. 所以个人建议:
    将登陆信息等重要信息存放为SESSION
    其他信息如果需要保留,可以放在COOKIE中

10.6 IO 和 NIO的区别,NIO优点

IO  NIO
面向流 面向缓冲
阻塞IO    非阻塞IO
无   选择器

10.7 一致性 Hash 算法

https://www.cnblogs.com/lpfuture/p/5796398.html

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

推荐阅读更多精彩内容