网站后期维护收费,可以做任务的创意设计网站,注册公司注册,网站建设新闻 常识1.http/1.1
tcp三次握手#xff08;syn#xff0c;syn ack ,ack)建立TCP连接。
1个网页一般由多个文件组成#xff0c;最基本的就是html、css、js和图片文件。对于http协议来说#xff0c;我们打开1个网页需要TCP三次握手#xff0c;建立TCP连接#xff0c;才正式进行请求…1.http/1.1
tcp三次握手synsyn ack ,ack)建立TCP连接。
1个网页一般由多个文件组成最基本的就是html、css、js和图片文件。对于http协议来说我们打开1个网页需要TCP三次握手建立TCP连接才正式进行请求。服务器先发送html文件给我们其他文件不会发给我吗。我们浏览器在收到html文件以后根据html里面的内容再向服务器一次请求Css、Js等文件。如果请求队伍里面有一个文件没有收到后面的文件也无法接收就会造成http队头阻塞。最老的http是一次一个请求响应。
http1.1默认说持久连接keep-alive请求和响应放在同一个连接里面但是只有一个连接速度太慢连接太多会造成DDos攻击。所以各家浏览器允许的持久连接数都不太相同。谷歌默认的是同时6个连接。http1.1当中有个管线化技术单个连接可以发送多个请求但是响应的时候按发送的顺序进行接收就会造成很大的执行难度。网络协议很难解决所以开发层面会将小图标全部做成一张图片在用js或者css把小图标分布到网站的各个部分减少请求次数。Data Urls图片用base64编码然后就可以以字符的形式写进html或者css里面但是编码的结果很长网站弄出多个域使得浏览器可以下载这些资源5张图片设置5个域名然后浏览器就会同时下载了就不用等前面资源下载后轮到下一个资源也就是域名分片但是开发复杂度提高把js、css加入到html中。
TCP三次握手、TCP慢启动减少网络的拥堵拥塞控制
http1.1的首部没有压缩且是明文。而且http1.1的请求和响应都有首部包括很多重复的开销。
2.http/2
http/2的多路复用解决http/1.1的队头阻塞问题减少了等待的时间。单个TCP连接进行交错发送请求和响应请求和响应互不影响。
请求和响应被划分成各个不同的帧。帧可以分为首部帧和数据帧。把原本HTTP报文的首部和实体拆分成2个部分。
http/2帧包括 长度、类型、标志、R、流标识符、负载
流标识符可以按照顺序进行组合而且帧类型中可以设置优先级标注流的权重。
http/2解决http/1.1的首部不压缩的问题也就是http2进行了首部压缩采用了HPACK的压缩算法。HPACK算法要求浏览器和服务器都保存一张静态只读的表。cookie的信息可以作为动态信息加入到动态表。Http/2的帧不是ASCII编码的报文而是被提前转化为二进制的帧解析起来更有效率。
服务器推送可能会造成DDos攻击有安全性问题
http/2解决了应用层面的问题但是http/2的传输层是基于tcp协议。tcp协议是由操作系统内核实现的。而且http2产生的那个年代也有tls了为了传输的安全性http2也会结合tls1.3一起使用可加可不加但是不加浏览器会有安全提示。
原本tls1.2对应四次挥手tls1.3调整成一来一回2次
3.http/3
http/3把tcp和tls的握手过程整合在一起了减少了来回的开销。传输层用的UDP协议并且添加了QUIC协议整合了TCP和TLS所以http3默认是使用加密传输。
QUIC帧包括类型、流标识符、偏移量、数据长度、负载
用连接ID标识为同一个连接。http3的应用层没有帧的概念把数据帧移到了QUIC帧里面相当于在传输层有了数据帧从源头解决数据阻塞的问题实现多路复用。QUIC帧被封装为QUIC数据包QUIC数据包包括标志、负载、连接ID。如果网络发送全面改变wifi变4G网络也就是Ip地址变了但是客户端和服务器端已经协商好了连接ID所以用连接id识别同一个连接避免再次握手。QUIC数据包把QUIC帧加密在TLS握手后QUIC帧被加密了QUIC数据包会被UDP封装成数据段UDP加上端口号。选择hhtp3进行通信QUIC就像TCP一样建立连接了。4.三次握手、四次挥手
1三次握手
套接字socketIP地址端口号
TCP报文有syn、ack和fin等标识1开启标识0关闭标识
1首先在客户端发送TCP报文的时候会把SYN开启同步
TCP是全双工的所以可以支持互发信息。
2服务器此时会把SYN和ACK确认开启服务器也生成自己的序号。确认号等于对方的序号1.
3客户端进行确认这边的序号用对方的确认号确认。握手之后建立连接客户端发起http请求服务器端响应内容。
版本2:
在该过程中发送了三包数据所以称为3次握手。
为什么要建立三次握手而不是两次握手。
服务端回复完SYNACK包就建立连接防止已失效的报文返回到服务器端引起错误。
比如SYN1包因为网络节点的原因被滞留所以重发SYN2包这次SYN2包顺利正常到达。服务端回复SYNACK包之后就建立了连接。第一包阻塞的节点又突然恢复第一包的SYN包又送到服务端。这时服务端会误认为是客户端又发起了1个新的连接。从而在 握手之后进入等待状态。也就是客户端认为是1个连接但是服务器端认为是2个连接造成了状态不一致。
三次握手中如果服务端收不到客户端的ACK包自然不会认为连接建立成功。三次握手是为了解决网络信道不可靠的问题。为了在不可靠的信道建立起可靠的连接。经过三次握手之后客户端和服务端都进入了数据传输状态。
一包数据可以拆成多包发送如何处理丢包问题。以及数据包到达的先后顺序不同如何处理乱序问题。t为了解决以上问题tcp为每一个连接建立发送缓冲区从建立连接后的第一个字节序列号为0后面的每个字节的序列号都会增加1.发送数据时从发送缓冲区取一部分数据组成发送报文在tcp头会附带序列号和长度接收端在收到数据后需要回复确认报文确认报文中的ACK序列号长度下一包起始序列号。能够使发送端确认发送的数据已经被对方收到。
为什么客户端要进行超时等待时间这时需要等待服务端收到ACK包。因为客户端在发送完最后一包ACK包就释放了连接。一旦ACK包在网络中丢失服务端就一直处于最后确认的状态。如果客户端发送最后一包ACK包后等待一段时间这时服务端因为没有收到ACK包会重发FIN包。客户端会响应这个FIN包重发ACK包并刷新超时时间。
··················
UDP协议是无连接的就是把数据包从网卡发送出去数据包之间并没有状态上的联系。资源占用少。
TCP(稳定可靠传输文件、发送邮件、浏览网页。
UDP速度快但是可能产生丢包适用于对实时性要求较高的对少量丢包并没有太大要求的场景。比如域名查询、视频直播、语音通话、VPN隧道网络。
三次握手解决信道不一致
2四次挥手
注意客户端和服务端都能发起 关闭请求。
假设是客户端主动发起关闭请求
客户端会在报文中开启FIN和ACK控制位
