大家好,我是温大大
最近温大大又又又整理了:万字网络协议方面的总结
主要覆盖:网络基础、TCP/UDP 高频面试题、HTTP 协议、Cookis/session、滑动窗口机制等知识点。
这次「网络八股文」配合前两次
Linux 万字总结
Mysql 入门到入土
这样同学们的基础八股文算是覆盖全了:数据库、Linux、网络 就像凑齐七龙珠能召唤1个神龙许愿1个愿望一样,如果你好好的阅读下温大大这三篇文章, 保证你能实现「涨薪」愿望呀。
温大大的肝算是快到爆穿了,只求各位同学帮忙一键三连:点赞、在看、转发
目录
OSI七层模型:
应用层:为应用程序提供网络服务;
表示层:数据格式转换、数据压缩和数据加密;
会话层:建立、断开和维护通信链接;
传输层:为上层协议提供端到端的可靠传输;
网络层:寻址和路由;
数据链路层:定义通过通信媒介互连的设备之间传输的规范;
物理层:利用物理传输介质为数据链路层提供物理连接。
TCP五层模型:
面向有连接
面向无连接型
相同:
区别:
FTP:文件传输协议; SSH:远程登录协议; HTTP:web服务器传输超文本到本地浏览器的超文本传输协议。 UDP对应的典型的应用层协议:
DNS:域名解析协议; TFTP:简单文件传输协议; SNMP:简单网络管理协议。
三次握手大概就是这么个过程。
至此,完成了握手过程,A知道B能收能发,B知道A能收能发,通信连接至此建立。 三次连接是保证可靠的最小握手次数,再多次握手也不能提高通信成功的概率,反而浪费资源。
备注:
第一次握手:
总结:A 发 (SYN=1,seq=x)到 B
第二次握手:
总结:B 发(SYN=1, ACK=1, seq=y, ack=x+1)到 A
第三次握手:
不可以。
防止已失效的连接请求报文段突然又传输到了服务端,导致产生问题。
比如客户端A发出连接请求,可能因为网络阻塞原因,A没有收到确认报文,于是A再重传一次连接请求。
连接成功,等待数据传输完毕后,就释放了连接。
然后A发出的第一个连接请求等到连接释放以后的某个时间才到达服务端B,此时B误认为A又发出一次新的连接请求,于是就向A发出确认报文段。
那为什么需要四次挥手呢?请看如下过程:
A向B发起请求,表示A没有数据要发送了:A——>B;
B向A发送信号,确认A的断开请求:B——>A;
B向A发送信号,请求断开连接,表示B没有数据要发送了:B——>A;
A向B发送确认信号,同意断开:A——>B。
B收到确认信号,断开连接,而A在一段时间内没收到B的信号,表明B已经断开了,于是A也断开了连接。至此,完成挥手过程。
可能有捧油会问,为什么2、3次挥手不能合在一次挥手中?那是因为此时A虽然不再发送数据了,但是还可以接收数据,B可能还有数据要发送给A,所以两次挥手不能合并为一次。
挥手次数比握手多一次,是因为握手过程,通信只需要处理连接。而挥手过程,通信需要处理数据+连接。
保证A发送的最后一个ACK报文段能够到达B。
防止已失效的连接请求报文段出现在本连接中。
短连接
长连接
长链接使用场景
短链接使用场景
区别1: 解析协议不同
区别2: HTTP2.0 采用多路复用(Mutiplexing)
区别3: http2.0 header压缩:
区别4: http2.0 服务端推送(server push):
HTTPS 默认工作在 TCP 协议443端口,它的工作流程一般如以下方式:
1、客户端发起 HTTPS 请求
2、服务端的配置
采用 HTTPS 协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请,区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面(startssl 就是个不错的选择,有 1 年的免费服务)。
这套证书其实就是一对公钥和私钥,如果对公钥和私钥不太理解,可以想象成一把钥匙和一个锁头,只是全世界只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。
3、传送证书
4、客户端解析证书
这部分工作是有客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。
如果证书没有问题,那么就生成一个随机值,然后用证书对该随机值进行加密,就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。
5、传送加密信息
6、服务端解密信息
7、传输加密后的信息
8、客户端解密信息
简介
制作过程
浏览器验证过程
对称加密:通信双方使用相同的密钥进行加密。特点是加密速度快,但是缺点是密钥泄露会导致密文数据被破解。常见的对称加密有AES和DES算法。
非对称加密:它需要生成两个密钥,公钥和私钥。公钥是公开的,任何人都可以获得,而私钥是私人保管的。公钥负责加密,私钥负责解密;或者私钥负责加密,公钥负责解密。这种加密算法安全性更高,但是计算量相比对称加密大很多,加密和解密都很慢。常见的非对称算法有RSA和DSA。
什么是Cookie(客户端技术)
Cookie实际上是一小段的文本信息。客户端请求服务器,如果服务器需要记录该用户状态,就使用response向客户端浏览器颁发一个Cookie。客户端会把Cookie保存起来。
当浏览器再请求该网站时,浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie,以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
信息保存的时间可以根据需要设置.
如果没有设置Cookie失效日期,它们仅保存到关闭浏览器程序为止.
如果将Cookie对象的Expires属性设置为Minvalue,则表示Cookie永远不会过期.
Cookie存储的数据量很受限制,大多数浏览器支持最大容量为4K,因此不要用来保存数据集及其他大量数据.
由于并非所有的浏览器都支持Cookie,并且数据信息是以明文文本的形式保存在客户端的计算机中,
因此最好不要保存敏感的,未加密的数据,否则会影响网站的安全性
什么是Session(服务端技术)
Session是另一种记录客户状态的机制,不同的是Cookie保存在客户端浏览器中,而Session保存在服务器上。客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
每个用户访问服务器都会建立一个session,那服务器是怎么标识用户的唯一身份呢?事实上,用户与服务器建立连接的同时,服务器会自动为其分配一个SessionId。
1、数据存储位置:cookie数据存放在客户的浏览器上,session数据放在服务器上。
2、安全性:cookie不是很安全,别人可以分析存放在本地的cookie并进行cookie欺骗,考虑到安全应当使用session。
3、服务器性能:session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能,考虑到减轻服务器性能方面,应当使用cookie。
4、数据大小:单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。
5、信息重要程度:可以考虑将登陆信息等重要信息存放为session,其他信息如果需要保留,可以放在cookie中。
在TCP协议当中窗口机制分为两种:
1.固定的窗口大小
2.滑动窗口
我们假设这个固定窗口的大小为1,也就是每次只能发送一个数据,只有接收方对这个数据进行了确认后才能发送第二个数据。在图中我们可以看到,发送方每发送一个数据接收方就要给发送方一个ACK对这个数据进行确认。只有接收了这个确认数据以后发送方才能传输下个数据。
存在的问题:如果窗口过小,当传输比较大的数据的时候需要不停的对数据进行确认,这个时候就会造成很大的延迟。
如果窗口过大,我们假设发送方一次发送100个数据,但接收方只能处理50个数据,这样每次都只对这50个数据进行确认。发送方下一次还是发送100个数据,但接受方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。
因此,我们引入了滑动窗口
1.滑动窗口概述
滑动窗口通俗来讲就是一种流量控制技术。
它本质上是描述接收方的TCP数据报缓冲区大小的数据,发送方根据这个数据来计算自己最多能发送多长的数据,如果发送方收到接收方的窗口大小为0的TCP数据报,那么发送方将停止发送数据,等到接收方发送窗口大小不为0的数据报的到来
2.工作原理
第一次发送数据这个时候的窗口大小是根据链路带宽的大小来决定的。
假设这时候的窗口是3.这个时候接收方收到数据以后会对数据进行确认告诉哦发送方我下次希望收到的数据是多少。
在上图中:我们看到接收方发送的ACK = 3(这是对发送方发送序列2的回答确认,下一次接收方期望接收到的是3序列信号),这个时候发送方收到这个数据以后就知道我第一次发送的3个数据对方只收到了两个,就知道第三个数据对方没有收到,下次返送的时候就从第3个数据开始发。这时候窗口大小就变为了2.
看到接收方发送的ACK是5就表示他下一次希望收到的数据是5,发送方就知道我刚才发送的2个数据对方收到了,这个时候开始发送第5个数据。
当链路变好或者变差,这个窗口还会发生变化,并不是第一次协商好了以后就永远不会变化了。
3.死锁状态
(1)概述:
(2)解决方法
4.TCP报文段的发送时机(传输效率问题)
可以用以下三种不同的机制控制TCP报文段的发送时机:
(1)TCP维持一个变量MSS,等于最大报文段的长度。只要缓冲区存放的数据达到MSS字节时,就组装成了一个TCP报文段发送出去
(2)由发送方的应用进程指明要发送的报文段,即:TCP支持推送操作
(3)发送方的一个计时器期限到了,这时就把当前已有的缓存数据装入报文段(但长度不能超过MSS)发送出去。
一、为何要进行拥塞控制?
为了方便,我们假设主机A给主机B传输数据。
我们知道,两台主机在传输数据包的时候,如果发送方迟迟没有收到接收方反馈的ACK,那么发送方就会认为它发送的数据包丢失了,进而会重新传输这个丢失的数据包。
然而实际情况有可能此时有太多主机正在使用信道资源,导致网络拥塞了,而A发送的数据包被堵在了半路,迟迟没有到达B。这个时候A误认为是发生了丢包情况,会重新传输这个数据包。
结果就是不仅浪费了信道资源,还会使网络更加拥塞。因此,我们需要进行拥塞控制。
二、如何知道网络的拥塞情况?
A 与 B 建立连接之后,就可以向B发送数据了,然而这个时候 A 并不知道此时的网络拥塞情况如何,也就是说,A 不知道一次性连续发送多少个数据包好,我们也把 A 一次性连续发送多少个数据包称之为拥塞窗口,用 N 代表此时拥塞窗口的大小吧。
为了探测网络的拥塞情况,我们可以采取以下两种策略:
1、先发送一个数据包试探下,如果该数据包没有发生超时事件(也就是没有丢包)。那么下次发送时就发送2个,如果还是没有发生超时事件,下次就发送3个,以此类推,即N = 1, 2, 3, 4, 5.....
2、一个一个增加实在是太慢了,所以可以刚开始发送1个,如果没有发生超时时间,就发送2个,如果还是没有发送超时事件就发送4个,接着8个...,用翻倍的速度类推,即 N = 1, 2, 4, 8, 16...
无论是第一种方法还是第二种方法,最后都会出现瓶颈值。不过这里值得注意的是,第一种情况的增长速率确实有点慢,但是第二种情况以指数增长,增长速度有点太快了,可能一下子就到瓶颈值了。
为了解决这个过慢或过快的问题,我们可以把第一种方法和第二种方法结合起来。也就是说,我们刚开始可以以指数的速度增长,增长到某一个值,我们把这个值称之为阈值吧,用变量 ssthresh 代替。当增长到阈值时,我们就不在以指数增长了,而是一个一个线性增长。
所以最终的策略是:前期指数增长,到达阈值之后,就以一个一个线性的速度来增长。
我们也把指数增长阶段称之为慢启动,线性增长阶段称之为拥塞避免
三、到了瓶颈值之后怎么办? 无论是指数增长还是一个一个增长,最终肯定会出现超时事件,总不可能无限增长吧。当出现超时事件时,我们就认为此时网络出现了拥塞了,不能再继续增长了。我们就把这个时候的N的值称之为瓶颈值吧,用MAX 这个字母来代替吧,即最大值。
注:这里再次提醒阈值过后是一个一个线性增长,图中之所以弯曲是因为我画图原因导致的
当达到最大值MAX之后,我们该怎么办呢?
当到达最大值之后我们采取的策略是这样的:
我们就回到最初的最初的状态,也就是说从1,2,4,8.....开始,不过这个时候我们还会把ssthresh调小,调为MAX值的一半,即ssthresh = MAX / 2。
图中阈值为8,瓶颈值是14;超时事件发生后,阈值为14 / 2 = 7。
四、超时事件就一定是网络拥塞? 超时事件发送就一定是网络出现了拥堵吗?其实也有可能不是出现了网络拥堵,有可能是因为某个数据包出现了丢失或者损害了,导致了这个数据包超时事件发生了
为了防止这种情况,我们是通过冗余 ACK来处理的。我们都知道,数据包是有序号的,如果A给B发送M1, M2, M3, M4, M5...N个数据包,如果B收到了M1, M2, M4....却始终没有收到M3,这个时候就会重复确认M2,意在告诉A,M3还没收到,可能是丢失
当A连续收到了三个确认M2的ACK,且M3超时事件还没发生。A就知道M3可能丢失了,这个时候A就不必等待M3设置的计时器到期了,而是快速重传M3。并且把ssthresh设置为MAX的一半,即ssthresh = MAX/2,但是这个时候并非把控制窗口N设置为1,而是让N = ssthresh,N在一个一个增长。
我们也把这种情况称之为快速恢复。而这种具有快速恢复的TCP版本称之为TCP Reno。
还有另外一种TCP版本,无论是收到三个相同的ACK还是发生超时事件,都把拥塞窗口的大小设为1,从最初状态开始,这种版本的TCP我们称之为TCP Tahoe。
让拥塞窗口cwnd缓慢地增大,每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长。
无论在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(其根据就是没有收到确认),就要把慢开始门限ssthresh设置为出现拥塞时的发送 方窗口值的一半(但不能小于2)。然后把拥塞窗口cwnd重新设置为1,执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数,使得发生 拥塞的路由器有足够时间把队列中积压的分组处理完毕。
有时个别报文段会在网络中丢失,但实际上网络并未发生拥塞。如果发送方迟迟收不到确认,就会产生超时,就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开始,把拥塞窗口cwnd又设置为1,因而降低了传输效率。
快重传算法可以避免这个问题。快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认,使发送方及早知道有报文段没有到达对方。
发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待重传计时器到期。由于发送方尽早重传未被确认的报文段,因此采用快重传后可以使整个网络吞吐量提高约20%。
当发送方连续收到三个重复确认,就会把慢开始门限ssthresh减半,接着把cwnd值设置为慢开始门限ssthresh减半后的数值,然后开始执行拥塞避免算法,使拥塞窗口缓慢地线性增大。
在采用快恢复算法时,慢开始算法只是在TCP连接建立时和网络出现超时时才使用。 采用这样的拥塞控制方法使得TCP的性能有明显的改进。