基础知识
什么是连接
连接就是通信双方开辟所需要的资源,一个连接对应了通信双方各一个Socket,从而保证了链接的唯一性。
网络通信过程
以发送流程为例:
首先应用层将数据写入内核的send queue中,然后交由内核来完成数据传输,传输的过程中会经历多个网络分层,同时会需要多个协议来协助其传输,每个协议的加入都意味着给数据包多进行一次封装,一直到吧数据传递给链路层,在链路层数据会从路由表中一次一次的找到下一个目标节点的MAC地址,从而一步一步的发送到接收方主机,接收方接受到的数据会被存在receive queue 中,同样依靠内核来将数据返回给应用层。
URL和URI
URI是指各种能够唯一表示资源的方式,URL便是用定位的方式表示资源的一种形式
网络分层(TCP/IP体系结构)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fTvlUeEd-1631467315700)(E:/note/%25E6%2588%2591%25E7%259A%2584%25E7%25AC%2594%25E8%25AE%25B0/%25E5%258A%25A0%25E5%25BC%25BA%25E3%2580%2581%25E5%258E%259F%25E7%2590%2586/upload/TCPIP%25E4%25BD%2593%25E7%25B3%25BB%25E7%25BB%2593%25E6%259E%2584.png)]
单播、多播、广播
广播和组播常用于局域网,例如我要给局域网的其他主机发送100份1G的文件,如果使用单播,那么将需要发送端在自己的主机上进行100次的报文复制,但是如果使用多播,那么这件事将由路由器和交换机来做,从而大大降低了当前主机的负载。广播时就是向其255的广播地址发送数据
HTTP
GET和POST
- GET 通过地址传输数据,POST通过请求体传输数据
- GET在地址中传输数据会有长度限制,如果长度超过限制,会返回414错误码。而Post在请求体中传输就不会有该问题
- GET请求在地址中传输的数据只接收部分ASCII码,我们平时之所以能够在GET中数据汉字,是因为浏览器用URL编码对其进行了处理,而POST在请求体中传输数据时就没有数据类型的限制
- GET请求一般用来获取数据,所以请求可以被浏览器缓存,但是POST一般用来处理数据,所以不会缓存
- GET请求被刷新是无害的,而刷新POST默认是非幂等的。
响应码
2XX
200:请求成功
204:响应中不包含主体(适用于客户端给服务端发送信息,且服务端不需要向客户端反馈信息)
206:只请求资源的一部分
3XX
301:永久重定向,例如为了让人们更方便的访问网站,我们申请www.abc.com和abc.com,但是其实资源放在www.abc.com的主机下,我们就可以将来自abc.com的所有请求301到www.abc.com
302:临时重定向,即临时调用另一个请求
4XX
400:请求报问存在语法错误
401:未认证
403:无权访问
404:无资源
405:方法不允许
414 :URI太长
415:不支持附带的媒体格式
5XX
500:服务器内部错误
503:服务不可用,服务器过载
报头
公共头 | |
---|---|
Remote Address | 请求的远程地址 |
Request URL | 请求的域名 |
Request Method | 页面请求的方式:GET/POST |
Status Code | 请求的返回状态 |
请求头 | |
---|---|
Cache-Control | 如何获取数据,比如是否查缓存,是否接收过期响应等。 |
Accept | 浏览器允许的MIME类型(MIME:用于告诉浏览器数据格式),早期HTTP并不附带数据类型信息,所有数据都被是为HTML,为了支持多媒体数据,所以用MIME指定其格式 |
Cooike | |
Connection | 是否长连接 |
Host | 请求域名 |
Referer | 请求来源 |
响应头 | |
---|---|
Cache-Control | 告诉浏览器缓存策略 |
Content-Encoding | 数据在传输过程中所使用的压缩编码方式 |
Content-Type | 数据的类型 |
Date | 数据从服务器发送的时间 |
特点
- 基于TCP/IP协议来传输数据
- 简单:只需要指定请求方法和请求路径即可访问服务器资源
- 灵活:允许传输任意类型的数据,可以在Content-Type加以标记
- 无连接:每个连接只处理一个请求,所以为无连接(但是新版本的长连接和多路复用打破了无连接)
- 无状态:对请求没有记忆能力(但是引入Cookie之后,请求已经变成了有状态的)
- 支持BS和CS
缺点
- 不加密:数据在网络中传输时,在各个节点都可能被窃听。
- 不认证:通信方容易遭伪装,对于自己接收到的请求来者不拒,可能遭受DOS攻击(发送大量合法请求,耗尽服务器资源或攻击安全漏洞)等。
- 无法验证数据,数据可能被篡改,即所谓的中间人攻击。
请求方法
- GET :获取资源
- POST:传输实体主体
- PUT:传输文件(自身不带验证机制,不安全,配合应用程序的验证才能保证安全)
- HEAD:获得报文首部(用于确认URI是否有效及资源的更新日期)
- DELETE:删除文件(与PUT一样,不带验证机制,需要上层应用进行验证)
- OPTIONS:询问该资源支持访问的方法(在跨域时,首先发送POTIONS进行预检)
HTTP1.0 HTTP1.1
-
长短连接:HTTP1.0的每个请求都会创建一个连接来处理Connecttion:keep-alive/close
HTTP1.1默认长连接,可以使得连接可以复用,从而减少了频繁创建、关闭连接的性能损耗
-
节约宽带:在请求头中引入了Range字段,从而可以只请求资源的某个部分,响应码为206,还可以只请求Head
-
HTTP1.1提供了更多的缓存相关字段来控制缓存,例如If-Match等等
-
HTTP1.1提供了更多的错误通知
-
HTTP1.0认为每台服务器仅对应唯一的IP,而随着虚拟技术的发展,一台物理的服务器可以存在多个虚拟主机,他们共享着一个IP地址,所以多个域名可能解析出同一个IP,通过在Host字段中指定其主机名或域名的URI来支持访问虚拟主机。HTTP1.1规定了请求消息必须携带HOST字段。
缺点 对头阻塞
(解决方法:并发连接,但是这个有限制,对于同一个域名下chrome上限为6。域名分片:因为并发连接被在同域名这个条件限制,所以可以将资源放在多个域名下)
HTTP2.0
- 多路复用:一个HTTP2.0的连接可以并发的处理多个请求,而1.1只能通过创建多个连接来同时处理多个请求。使得一个连接处理多个请求,chrme最多6个连接。
- 头部压缩:HTTP2.0支持对消息的Header进行压缩,使得数据体更小,传输更快。
- 服务端推送:在客户端没有主动发出请求时,HTTP2.0也可以主动向客户端推送数据。比如访问页面的时候,必定会请求其css/js文件,可以使用服务端推送的方式直接推给客户端,从而减少了请求量
- 二进制分帧:HTTP2.0将消息分成更小的帧发送,这些帧可以乱序发送和双向传输,送达之后将通过帧首部的流标识对其进行重新组装。
- 请求优先级:Http2.0支持对请求设置优先级,优先级高的请求将被优先响应。比如请求页面时,css/js这些比较重要的就应该让其先去请求。
队头阻塞
- Http1.0时,因为其基于请求–响应这种一来一回的形式,所以一旦某个请求被阻塞,那么后续请求都会被阻塞。
- Http1.1时,采用管道化的方式,可以使得请求在未收到响应时,再向服务端继续发送请求。但是其要求服务端在返回响应的时候,必须按照请求的顺序返回。所以一旦某个响应被阻塞,后续响应就都会被阻塞,并且仍然需要保持其他连接。
- Http2.0时,采用二进制分帧的方式,将消息拆分成更小的帧,乱序发送,送达之后再组合起来。但是由于其依旧是基于TCP实现的,所以TCP传输的时候依旧会把数据按序发送,一旦某个数据包没有被按序到达,那么依旧会阻塞后续请求。
- Http3.0将会改造UDP来实现Http3.0
HTTPS
HTTPS = HTTP + 加密 + 认证 + 完整性保护;
HTTPS :Http-Over-TLS 即运行在tls之上的http协议
实现方式
加密:通过非对称加密的方式交换对称加密密钥
认证:采用证书,以防中间人攻击
完整性保护:传输数据丢失附带MAC消息认证码
流程
通过证书来避免中间人攻击,由TLS采用非对称加密的方式来保证安全的写上对称加密的密钥
证书颁发
证书是由CA使用自己的私钥,将服务端的域名、公钥以及证书颁发时间、颁发机构、有效时间等等数据进行加密而生成的。客户端操作系统会内置被广泛认可的一些CA。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-klDUQoOT-1631467315704)(upload%5Cimage-20210330210846594.png)]
Http和Https的区别
- Http明文传输,Https密文传输
- Http直接和TCP通信,Https直接和SSL通信
- Http是80端口,Https是443端口
- Https在通信时有认证和完整性保护
TLS
TLS和SSL的关系
TLS基于SSL实现,所以TLS其实就是SSL的加强版
工作流程
- 客户端发出请求告诉自己支持的协议版本及加密方式,和一个随机数A
- 服务端返回给客户端本次通信使用哪种协议,使用哪种加密方式,并返回一个服务端产生的随机数B以及服务端的证书
- 客户端验证证书
- 客户端接收到服务端的随机数B,并自己再生成随机数C,客户端会根据随机数ABC计算出后续对称加密使用的密钥。客户端使用证书公钥解密出证书中的服务端公钥,用服务端公钥加密随机数C,将其发送给服务端
- 客户端将之前发送的数据进行hash1,并用secret key加密返回给服务端
- 客户端告诉服务端,之后使用secret key进行加密通信
- 服务端使用自己的私钥解密出随机数C,采用同样方式生成secret key,用其解密出hash1。并用自己接受到的数据进行计算得到hash2,比对hash1和hash2是否相同
- 服务端告诉客户端,之后使用secret key进行加密通信
- 服务端将hash2返回给客户端
TCP
TCP三次握手
为了保证可靠性,所以要每次握手时要传递一个序列号,以保证其响应的消息正确
- Client给Server发送同步消息SYN,等待Server确认
- Server接收到同步消息点后给Client返回确认消息ACK,同时Server发送同步消息SYN,等待Client确认
- Client给Server返回确认消息,表示Client已经接受到了Server发来的确认消息
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-V4qWCHsX-1631467315707)(E:/note/%25E6%2588%2591%25E7%259A%2584%25E7%25AC%2594%25E8%25AE%25B0/%25E5%258A%25A0%25E5%25BC%25BA%25E3%2580%2581%25E5%258E%259F%25E7%2590%2586/upload/image-20210317213109541.png)]
TCP四次挥手
-
Client发送关闭消息FIN,表示Client请求关闭连接,并且Client进入等待关闭状态
-
Server发送确认消息ACK,表示Server已经知晓Client请求关闭连接,但是此时Server可能还有没发送完的数据
-
待Server发送完数据后,向Clietn发送结果关闭消息FIN,表示服务端要向客户端发送的数据已经发送完了,Client可以关闭了,Server自己也要关闭了。
-
Client接收到Server的关闭消息后,向Server发送一个确认消息ACK,表示Client知晓Server即将关闭,并且自己进入超时等待状态,Server接受到ACK后,便关闭连接,经过两个最大报文段生存时间后,客户端也将关闭连接。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gCN5GuBj-1631467315714)(E:/note/%25E6%2588%2591%25E7%259A%2584%25E7%25AC%2594%25E8%25AE%25B0/%25E5%258A%25A0%25E5%25BC%25BA%25E3%2580%2581%25E5%258E%259F%25E7%2590%2586/upload/image-20210317213049133.png)]
为什么需要等两个MSL
- 因为有可能最后服务端没有收到ACK,那么将会超时重传,而客户端知道服务端没有收到消息取决于是不是收到了服务端上次发来的FIN,这两个过程总共最多经历2MSL(报文最长生存时间)
- 若客户端直接关闭,那么服务端将有可能立马使用刚才的端口再创建一个连接,但是此时仍有可能旧连接的消息还存在于信道中,所以需要等待一会让信道中的数据消亡。
如何保证可靠传输
校验和:校验TCP首部、数据
确认应答及重传:接收端收到数据后会给发送端返回一个ACK的确认,如果接收端未发送或者客户端未收到或者序列号错乱,那么发送端就会重发该数据(重传时间会比往返+网络抖动值略大一点),并且序列号可以保证数据有序,并且可以以序列号来去重。
流量控制
目的:避免接收方承受不了巨大的压力
实现:在TCP报头中,维护一个叫Window的窗口,用来描述接收端的承受能力。
拥塞控制
目的:充分利用网络资源
由于滑动窗口控制,所以在TCP通信时,可以同时传输多个数据段,但是当网络中传输过多数据时,网络便会阻塞,甚至瘫痪。
代表算法:Reno(基于丢包实现,其他还有基于时延和链路容量的实现)
实现:慢启动、拥塞避免、快重传、快恢复
一开始发送端翻倍式的发送大量数据,来测试网络状态,一旦发生丢包就将拥塞窗口减半,并进入拥塞避免状态,该状态会继续尝试增大拥塞窗口,一旦发现丢包就立刻重发,并将窗口再次减半,并且重新进入拥塞避免状态。
TCP如何实现长连接
所谓的一个连接其实就是在通信双方开始资源,长链接就是说开辟的资源可以多次被使用,TCP采用心跳机制,由发送端定时给接收端发送探测报文,以此来判断接收端是否还存活,若存活就依旧开放资源,否则关闭资源。
长链接的使用
在NTLM认证中,客户端需要给服务端发送type1msg,然后服务端返回type2msg,客户端再通过type2msg来计算出type3msg并发送给服务端,在这个过程中服务端必须保证是长链接,否则他讲吧所有的请求都视为是在接收type1msg。
在创建TCP连接时候,第一次握手就会计算出MSS
粘包拆包
因为TCP是面向字节流的,发送的是字节流,因此有时会将小尺寸数据封装在一个TCP报文中发送。
解决办法:1.固定发送数据的长度 2.将两个信息之间用间隔符隔开。
UDP
为什么不可靠
- UDP不会在意接收方数据是否收到,不会像TCP有重传机制,若数据在发送过程中网络出现了波动等情况,数据将丢失。
- 因为UDP无连接,所以若在数据传输中途,有其他进程向该端口发送 了数据,那么数据将被干扰。
- 因为UDP无连接,所以不知道接收端的状态,那么一些发送可能就是无效的。
- 因为UDP没有流量控制,并且发送端并不清楚接收端的接收能力,如果数据量太大,可能会导致接收端的接收缓冲区溢出,导致数据丢失。
TCP和UDP的区别
- TCP可靠 UDP不可靠,所以UDP自然没有TCP用来保证可靠性的各种机制
- TCP面向字节流,以数据段为传输单位,而UDP以数据包为传输单位
- TCP有连接,UDP无连接
- TCP一对一,UDP可以一对一、一对多、多对多
DNS劫持
就是在DNS解析的过程中,给客户端返回一个虚假的地址,结果会导致:访问的是正确的域名,但实际却访问了虚假的网站。
ARP
适用范围:局域网通信
前置知识:局域网通信使用的是MAC地址
工作流程:主机A要和主机B通信,所以需要获取主机B的MAC地址,首先查询自己的ARP缓存,如果缓存中不存在,那么主机A先广播一个ARP请求,其中携带上自己的IP和MAC地址以及目标地址的IP,局域网中的每台主机检查ARP的IP是否和自己匹配,如果不匹配则丢弃该包,若匹配,那么得到ARP响应后,将IP和MAC的键值对缓存,缓存会有有效期限制。
DOS攻击:伪造ARP应答,将请求的IP地址对应的MAC地址替换成攻击者的MAC地址,那么数据就会发送到攻击主机上。原因:ARP是无状态协议,无法判断接收到的应答是否来自自己发出的请求。
中间人攻击:攻击者将ARP请求的MAC地址和ARP响应的MAC地址都换成自己的
输入URL到显示
- DNS解析(Host文件、各种缓存、DNS服务器)
- TCP三次握手
- TLS四次握手
- 发送HTTP请求并返回报文
- 浏览器渲染页面