山东省建设部继续教育网站,自己做的网站怎么在百度上搜到,杭州家具网站建设方案,綦江建设银行网站!-- GFM-TOC --
计算机网络体系结构 传输层#xff1a;TCP和UDP 什么是三次握手#xff1f; 什么是四次挥手#xff1f; TCP如何实现流量控制#xff1f; TCP的拥塞控制是怎么实现的#xff1f; TCP如何最大利用带宽#xff1f; TCP与UDP的区别 TCP如何保…!-- GFM-TOC --
计算机网络体系结构 传输层TCP和UDP 什么是三次握手 什么是四次挥手 TCP如何实现流量控制 TCP的拥塞控制是怎么实现的 TCP如何最大利用带宽 TCP与UDP的区别 TCP如何保证传输的可靠性 什么是TCP粘包 应用层HTTP和HTTPS HTTP和HTTPS有什么区别 GET与POST的区别 Session与Cookie的区别 从输入网址到获得页面的过程 (越详细越好) HTTP请求有哪些常见状态码 什么是RIP (距离矢量路由协议)? 网络层协议 IP地址的分类 什么叫划分子网 什么是ARP协议 什么是NAT (网络地址转换) 参考 !-- GFM-TOC -- 计算机网络体系结构 osi七层参考模型tcp/ip五层或四层 分层是为了给网络协议的设计提供一个结构每一层向它的上一层提供服务采用自上而下的方法研究其原理。 OSI中的表示层主要包括数据压缩数据加密和数据描述会话层提供了数据交换的功能
应用层存放网络应用程序和网络协议包括许多常见协议。应用层只需要专注于为用户提供应用功能。
应用层是工作在操作系统中的用户态传输层及以下则工作在内核态。
ping FTP(21端口)文件传输协议
SSH(22端口)远程登陆
TELNET(23端口)远程登录
SMTP(25端口)发送邮件
POP3(110端口)接收邮件
HTTP(80端口)超文本传输协议
DNS(53端口)运行在UDP上域名解析服务
Socket应用层
传输层进行数据的传输为应用层提供网络支持。 两个传输协议TCP/UDP
大部分应用使用的是TCP比如http。 网络层寻址网络层负责将数据从一个设备传输到另一个设备。
不希望传输层协议处理太多的事情只需要服务好应用让传输层作为应用间数据传输的媒介帮助实现应用到应用的通信而实际的传输功能就交给下一层也就是网络层完成。
IP、ARP、NAT、RIP、...路由器
通过IP地址进行寻址根据IP地址和子网掩码可以计算出网络号标识属于哪个子网和主机号标识子网下的不同主机。
IP协议还有路由的功能当数据包到达一个网络节点就需要通过路由算法决定下一步走哪条路径。
10.100.122.0/24后面的/24表示就是 255.255.255.0 子网掩码共24个1.10.100.122.2 和 255.255.255.0 进行按位与运算就可以得到网络号。255.255.255.0 取反后与IP地址进行按位与运算就可以得到主机号。
链路层把数据包从一个节点主机或路由器运输到另一个节点。
以太网接入的DOCSIS协议,MAC地址IP地址为32位MAC地址为48位网桥交换机
物理层把一个个比特从一个节点运到另一个节点。协议与实际的物理传输介质有关。
中继器、集线器
TCP基本概念
TCP面向连接的、可靠的、基于字节流的传输层通信协议
为什么需要 TCP
IP层是不可靠的不能保证网络包的交付按序交付以及数据的完整性。要保证网络数据包的可靠性需要上层传输层的tcp协议负责。
TCP四元组可以唯一的确定一个连接源地址源端口目的地址目的端口。
源地址和目的地址32位在IP头部通过IP协议发送吧报文给对方主机。
源端口和目的端口16位在TCP头部告诉TCP协议应该把保文发给哪个进程。 TCP头格式源端口号序列号确认应答号控制位数据。
序列号seq建立连接时由计算机生成的随机数作为其初始值通过SYN包传给接收端主机每发送一次数据就累加一次该数据字节数的大小。用来解决网络包乱序问题。
确认应答号ack指下一次期望收到的数据的序列号发送端收到这个确认应答后可以认为在这个序列号以前的数据都已经被正常接收。用来解决丢包的问题。
控制位
SYN该位为1时表示希望建立连接并在其【序列号】的字段进行序列号初始值的设定。
FIN该位为1时表示今后不会再有数据发送希望【断开连接】。当通信结束希望断开连接时通信双方的主机之间就可以相互交换FIN位为1的TCP段。
ACK该位为1时【确认应答】的字段变为有效TCP规定除了最初建立连接时的SYN包之外该位必须设置为1。
RST该位为1时表示TCP连接中出现异常必须强制断开连接。
三次握手 第一次握手客户端将SYN位置1随机产生一个初始序列号seq发送给服务端进入SYN_SENT状态保证了客户端的发送能力没问题 第二次握手服务端收到客户端的SYN1之后知道客户端请求建立连接将自己的SYN置1ACK置1产生一个确认应答号ackseq1并随机产生一个自己的初始序列号seq发送给客户端进入SYN_RCVD状态服务端的接收能力以及发送能力没问题 第三次握手客户端检查ack是否为序列号seq1ACK是否为1检查正确之后将自己的ACK置为1产生一个ack服务器发的序列号seq1发送给服务器进入ESTABLISHED状态服务器检查ACK为1和ack为序列号seq1之后也进入ESTABLISHED状态完成三次握手连接建立。保证客户端的接收能力没问题
可以两次握手吗
不可以。有两个原因
1.可能会出现已失效的连接请求报文段又传到了服务器端。
client 发出的第一个连接请求报文段并没有丢失而是在某个网络结点长时间的滞留了以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段同意建立连接。假设不采用 “三次握手”那么只要 server 发出确认新的连接就建立了。由于现在 client 并没有发出建立连接的请求因此不会理睬 server 的确认也不会向 server 发送数据。但 server 却以为新的运输连接已经建立并一直等待 client 发来数据。这样server 的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况client 不会向 server 的确认发出确认。server 由于收不到确认就知道 client 并没有要求建立连接。
2.两次握手无法保证Client正确接收第二次握手的报文Server无法确认Client是否收到也无法保证Client和Server之间成功互换初始序列号。
可以四次握手吗
可以。但是会降低传输的效率。
四次握手是指第二次握手Server只发送ACK和acknowledge number而Server的SYN和初始序列号在第三次握手时发送原来协议中的第三次握手变为第四次握手。出于优化目的四次握手中的二、三可以合并。
握手丢失会发生什么
第一次握手丢失了会发生什么
如果客户端迟迟借不到服务器SYN-ACK报文触发超时重传机制重传的SYN序号是一样的每次超时时间是上一次的2倍。也会又重传次数。当已经达到最大重传次数的时候等待一段时间时间是上一次超时重传的2倍如果还没有收到就会断开连接。
第二次握手丢失了会发生什么
客户端没有收到回触发超时重传机制重传SYN报文。
服务器端也没有收到ACK确认报文回触发超时重传机制重传SYN-ACK报文。 第三次握手如果客户端的ACK未送达服务器
Server端 由于Server没有收到ACK确认因此会重发之前的SYNACK默认重发五次之后自动关闭连接进入CLOSED状态Client收到后会重新传ACK给Server。
Client端两种情况 在Server进行超时重发的过程中如果Client向服务器发送数据数据头部的ACK是为1的所以服务器收到数据之后会读取 ACK number进入 establish 状态 在Server进入CLOSED状态之后如果Client向服务器发送数据服务器会以RST包应答。
如果已经建立了连接但客户端出现了故障怎么办
服务器每收到一次客户端的请求后都会重新复位一个计时器时间通常是设置为2小时若两小时还没有收到客户端的任何数据服务器就会发送一个探测报文段以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应服务器就认为客户端出了故障接着就关闭连接。
如果已经建立连接但是服务端进程崩溃回发生什么
TCP的连接信息是由内核维护的所以当服务器的进程崩溃后内核需要挥手该进程所有TCP连接资源于是你和核客户端完成TCP四次挥手。
初始序列号是什么
TCP连接的一方A随机选择一个32位的序列号Sequence Number作为发送数据的初始序列号Initial Sequence NumberISN比如为1000以该序列号为原点对要传送的数据进行编号1001、1002...三次握手时把这个初始序列号传送给另一方B以便在传输数据时B可以确认什么样的数据编号是合法的同时在进行数据传输时A还可以确认B收到的每一个字节如果A收到了B的确认编号acknowledge number是2001就说明编号为1001-2000的数据已经被B成功接受。
什么是SYN攻击如何避免
TCP三次握手攻击者短时间伪造SYN服务器回回应SYN——ACK但是得不到回应久而久之就会沾满服务器的半连接队列使得服务器不能为正常用户服务。
SYN 攻击方式最直接的表现就会把 TCP 半连接队列打满这样**当 TCP 半连接队列满了后续再在收到 SYN 报文就会丢弃**导致客户端无法和服务端建立连接。
避免 SYN 攻击方式可以有以下四种方法 调大 netdev_max_backlog 增大 TCP 半连接队列 开启 tcp_syncookies 减少 SYNACK 重传次数
四次挥手 第一次挥手Client将FIN置为1发送一个序列号seq给Server进入FIN_WAIT_1状态 第二次挥手Server收到FIN之后发送一个ACK1acknowledge number收到的序列号1进入CLOSE_WAIT状态。此时客户端已经没有要发送的数据了但仍可以接受服务器发来的数据。 第三次挥手Server将FIN置1发送一个序列号给Client进入LAST_ACK状态 第四次挥手Client收到服务器的FIN后进入TIME_WAIT状态接着将ACK置1发送一个acknowledge number序列号1给服务器服务器收到后确认acknowledge number后变为CLOSED状态不再向客户端发送数据。客户端等待2*MSL报文段最长寿命时间后也进入CLOSED状态。完成四次挥手。
为什么不能把服务器发送的ACK和FIN合并起来变成三次挥手CLOSE_WAIT状态意义是什么
因为服务器收到客户端断开连接的请求时可能还有一些数据没有发完这时先回复ACK表示接收到了断开连接的请求。等到数据发完之后再发FIN断开服务器到客户端的数据传送。
如果第二次挥手时服务器的ACK没有送达客户端会怎样
客户端没有收到ACK确认会重新发送FIN请求。
客户端TIME_WAIT状态的意义是什么
第四次挥手时客户端发送给服务器的ACK有可能丢失TIME_WAIT状态就是用来重发可能丢失的ACK报文。如果Server没有收到ACK就会重发FIN如果Client在2*MSL的时间内收到了FIN就会重新发送ACK并再次等待2MSL防止Server没有收到ACK而不断重发FIN。
MSL(Maximum Segment Lifetime)指一个片段在网络中最大的存活时间2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSLClient都没有再次收到FIN那么Client推断ACK已经被成功接收则结束TCP连接。
大量的 TIME_WAIT 状态 TCP 连接存在其本质原因是什么
1.大量的短连接存在
2.特别是 HTTP 请求中如果 connection 头部取值被设置为 close 时基本都由「服务端」发起主动关闭连接
3.而TCP 四次挥手关闭连接机制中为了保证 ACK 重发和丢弃延迟数据设置 time_wait 为 2 倍的 MSL报文最大存活时间
TIME_WAIT 状态
1.TCP 连接中主动关闭连接的一方出现的状态收到 FIN 命令进入 TIME_WAIT 状态并返回 ACK 命令
2.保持 2 个 MSL 时间即4 分钟MSL 为 2 分钟
解决办法 解决上述 time_wait 状态大量存在导致新连接创建失败的问题一般解决办法
1.客户端HTTP 请求的头部connection 设置为 keep-alive保持存活一段时间现在的浏览器一般都这么进行了
2.服务器端
允许 time_wait 状态的 socket 被重用
缩减 time_wait 时间设置为 1 MSL TCP如何实现流量控制
TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量这就是所谓的流量控制。
窗口大小由接收方控制。 使用滑动窗口协议实现流量控制。防止发送方发送速率太快接收方缓存区不够导致溢出。接收方会维护一个接收窗口 receiver window窗口大小单位是字节接受窗口的大小是根据自己的资源情况动态调整的在返回ACK时将接受窗口大小放在TCP报文中的窗口字段告知发送方。发送窗口的大小不能超过接受窗口的大小只有当发送方发送并收到确认之后才能将发送窗口右移。
发送窗口的上限为接受窗口和拥塞窗口中的较小值。接受窗口表明了接收方的接收能力拥塞窗口表明了网络的传送能力。 什么是零窗口接收窗口为0时会怎样
如果接收方没有能力接收数据就会将接收窗口设置为0这时发送方必须暂停发送数据但是会启动一个持续计时器(persistence timer)到期后发送一个大小为1字节的探测数据包以查看接收窗口状态。如果接收方能够接收数据就会在返回的报文中更新接收窗口大小恢复数据传送。
/details
窗口关闭潜在的危险
当发生窗口关闭时接收方处理完数据后会向发送方通告一个窗口非 0 的 ACK 报文如果这个通告窗口的 ACK 报文在网络中丢失了那麻烦就大了。
这会导致发送方一直等待接收方的非 0 窗口通知接收方也一直等待发送方的数据如不采取措施这种相互等待的过程会造成了死锁的现象。
TCP 是如何解决窗口关闭时潜在的死锁现象呢
TCP 为每个连接设有一个持续定时器只要 TCP 连接一方收到对方的零窗口通知就启动持续计时器。如果持续计时器超时就会发送窗口探测 ( Window probe ) 报文而对方在确认这个探测报文时给出自己现在的接收窗口大小。
TCP的拥塞控制是怎么实现的
其实只要「发送方」没有在规定时间内接收到 ACK 应答报文也就是发生了超时重传就会认为网络出现了拥塞 拥塞控制主要由四个算法组成慢启动Slow Start、拥塞避免Congestion voidance、快重传 Fast Retransmit、快恢复Fast Recovery 慢启动刚开始发送数据时先把拥塞窗口congestion window设置为一个最大报文段MSS的数值每收到一个新的确认报文之后就把拥塞窗口加1个MSS。这样每经过一个传输轮次或者说是每经过一个往返时间RTT拥塞窗口的大小就会加倍 拥塞避免当拥塞窗口的大小达到慢开始门限(slow start threshold)时开始执行拥塞避免算法拥塞窗口大小不再指数增加而是线性增加即每经过一个传输轮次只增加1MSS. 无论在慢开始阶段还是在拥塞避免阶段只要发送方判断网络出现拥塞其根据就是没有收到确认就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半但不能小于2。然后把拥塞窗口cwnd重新设置为1执行慢开始算法。这是不使用快重传的情况 快重传快重传要求接收方在收到一个失序的报文段后就立即发出重复确认为的是使发送方及早知道有报文段没有到达对方而不要等到自己发送数据时捎带确认。快重传算法规定发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段而不必继续等待设置的重传计时器时间到期。 快恢复当发送方连续收到三个重复确认时就把慢开始门限减半然后执行拥塞避免算法。不执行慢开始算法的原因因为如果网络出现拥塞的话就不会收到好几个重复的确认所以发送方认为现在网络可能没有出现拥塞。 也有的快重传是把开始时的拥塞窗口cwnd值再增大一点即等于 ssthresh 3*MSS 。这样做的理由是既然发送方收到三个重复的确认就表明有三个分组已经离开了网络。这三个分组不再消耗网络的资源而是停留在接收方的缓存中。可见现在网络中减少了三个分组。因此可以适当把拥塞窗口扩大些。
有了流量控制为啥还要拥塞控制 TCP如何保证传输的可靠性 数据包校验 对失序数据包重新排序TCP报文具有序列号 丢弃重复数据 应答机制接收方收到数据之后会发送一个确认通常延迟几分之一秒 超时重发发送方发出数据之后启动一个定时器超时未收到接收方的确认则重新发送这个数据 流量控制确保接收端能够接收发送方的数据而不会缓冲区溢出
TCP如何最大利用带宽
TCP速率受到三个因素影响 窗口即滑动窗口大小见TCP如何实现流量控制 带宽这里带宽是指单位时间内从发送端到接收端所能通过的“最高数据率”是一种硬件限制。TCP发送端和接收端的数据传输数不可能超过两点间的带宽限制。发送端和接收端之间带宽取所通过线路的带宽最小值如通过互联网连接。 RTT即Round Trip Time表示从发送端到接收端的一去一回需要的时间TCP在数据传输过程中会对RTT进行采样即对发送的数据包及其ACK的时间差进行测量并根据测量值更新RTT值TCP根据得到的RTT值更新RTO值即Retransmission TimeOut就是重传间隔发送端对每个发出的数据包进行计时如果在RTO时间内没有收到所发出的数据包的对应ACK则任务数据包丢失将重传数据。一般RTO值都比采样得到的RTT值要大。
带宽时延乘积
带宽时延乘积带宽*RTT实际上等于发送端到接收端单向通道的数据容积的两倍这里单向通道的数据容积可以这样来理解单向通道看成是一条单行道马路带宽就是马路的车道数路上跑的汽车就是数据不过这里所有汽车的速率都是一样的且不会有人想超车大家齐头并进那么单向通道的数据容积就是这条单行道上摆满车一共可以摆多少辆。带宽就是马路的车道数带宽数乘以单向通道的数据容积就是路面上所能容纳的全部数据量。当路面上已经摆满的时候就不能再往里面放了。 /details
设滑动窗口大小为 发送端和接收端的带宽为 RTT为。
前面已经说过了TCP发送数据时受滑动窗口的限制当TCP将滑动窗口中的数据都发出后在收到第一个ACK之前滑动窗口大小是0不能再发送数据了必须等待ACK包使滑动窗口移动。那么在理想情况下ACK包应该在什么时候到达呢显然就是在数据发出后的RTT时间后ACK包到达。这也就是说现在在不考虑丢包和拥塞情况下TCP在一个RTT时间内能发出的最大数据量为 所以不考虑带宽限制下TCP能一个时刻能达到的最大速度是 。
现在再考虑带宽限制前面说过当马路上摆满车的时候就无法再往里放车了同理TCP发送端在 时间内能往通道上放的最大数据量为 通过带宽时延乘积得到的容积限制为 。当 时单向通道容积不构成瓶颈速率的限制主要来源于窗口大小限制。而当 时则就受到容积限制即此时速率限制来源于带宽限制。
因此TCP的最大速率为
在我们平时生活中使用的宽带网络ADSL等环境下因为带宽都比较小从而 也比较小再加上网络情况比较复杂拥塞情况比较常见所以这些网络环境下TCP速率的主要限制因素在于带宽丢包率等。长肥管道一般不太常见多见于一些单位使用的专线网络在这些网络中速率的主要限制因素就是窗口大小了这也是传统TCP在这些网络环境中不能充分利用带宽的原因所在因为传统TCP的窗口大小是用2字节表示的所以最大只有65535不考虑窗口扩大选项除了专线网络外随着网络硬件技术的发展万兆交换机的出现局域网中也可能会出现带宽时延乘积较大的情况。
TCP重传机制
TCP实现可靠传输的方式之一是通过序列号与确认应答。
重传机制RTT往返时延数据发送时刻到接收到确认的时刻的差值
超时重传在发送数据时设定一个定时器当超过指定的时间后没有收到对方的 ACK 确认应答报文就会重发该数据也就是我们常 说的超时重传。RTO超时重传时间。超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。
快速重传Fast Retransmit机制快速重传的工作方式是当收到三个相同的 ACK 报文时会在定时器过期之前重传丢失的报文 段。
SACK 方法在 TCP 头部「选项」字段里加一个 SACK 的东西它可以将已收到的数据的信息发送给「发送方」这样发送方就可以知 道哪些数据收到了哪些数据没收到知道了这些信息就可以只重传丢失的数据。
Duplicate SACK使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。 TCP与UDP的区别
TCP传输控制协议 UDP用户数据报协议 TCP是面向连接的UDP是无连接的
UDP发送数据之前不需要建立连接。 TCP是可靠的UDP不可靠
UDP接收方收到报文后不需要给出任何确认。不能保证将数据传送到目标。
TCP 相比 UDP 多了很多特性比如流量控制、超时重传、拥塞控制等这些都是为了保证数据包能可靠地传输给对方。
UDP 也可以实现可靠传输把 TCP 的特性在应用层上实现就可以不过要实现一个商用的可靠 UDP 传输协议也不是一件简单的事情。 TCP只支持点对点通信UDP支持一对一、一对多、多对一、多对多 TCP是面向字节流的UDP是面向报文的
面向字节流是指发送数据时以字节为单位一个数据包可以拆分成若干组进行发送而UDP一个报文只能一次发完。TCP 报文是有序的当前一个TCP 报文没有收到的时候即使它先收到了后面的 TCP 报文那么也不能扔给应用层去处理同时对重复的 TCP 报文会自动丢弃。 传输方式不同 TCP是流式传输没有边界但保证顺序和可靠。
UDP是一个包一个包的发送是有边界的但可能会丢包和乱序。 TCP有拥塞控制机制UDP没有。 网络出现的拥塞不会使源主机的发送速率降低这对某些实时应用是很重要的比如媒体通信游戏 TCP首部开销20字节比UDP首部开销8字节要大 TCP头部还有序列号确认应答号控制位 UDP 的主机不需要维持复杂的连接状态表
什么时候选择TCP什么时候选UDP
对某些实时性要求比较高的情况选择UDP比如游戏媒体通信实时视频流直播即使出现传输错误也可以容忍其它大部分情况下HTTP都是用TCP因为要求传输的内容可靠不出现丢失
HTTP可以使用UDP吗
HTTP不可以使用UDPHTTP需要基于可靠的传输协议而UDP不可靠
注http 3.0 使用udp实现
面向连接和无连接的区别
无连接的网络服务数据报服务-- 面向连接的网络服务虚电路服务
虚电路服务首先建立连接所有的数据包经过相同的路径服务质量有较好的保证
数据报服务每个数据包含目的地址数据路由相互独立路径可能变化网络尽最大努力交付数据但不保证不丢失、不保证先后顺序、不保证在时限内交付网络发生拥塞时可能会将一些分组丢弃 从输入网址到获得页面的过程 浏览器查询 DNS获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询如果要查询的域名包含在本地配置区域资源中则返回解析结果给客户机完成域名解析(此解析具有权威性)如果要查询的域名不由本地DNS服务器区域解析但该服务器已缓存了此网址映射关系则调用这个IP地址映射完成域名解析此解析不具有权威性。如果本地域名服务器并未缓存该网址映射关系那么将根据其设置发起递归查询或者迭代查询 浏览器获得域名对应的IP地址以后浏览器向服务器请求建立链接发起三次握手 TCP/IP链接建立起来后浏览器向服务器发送HTTP请求 服务器接收到这个请求并根据路径参数映射到特定的请求处理器进行处理并将处理结果及相应的视图返回给浏览器 浏览器解析并渲染视图若遇到对js文件、css文件及图片等静态资源的引用则重复上述步骤并向服务器请求这些资源 浏览器根据其请求到的资源、数据渲染页面最终向用户呈现一个完整的页面。
地址栏输入URL发生了什么
在浏览器中输入网址按下回车后 1、DNS服务器进行域名映射找到访问的地址然后HTTP客户端进程在80端口发起一个服务器到访问地址的TCP连接在客户和服务器进程中各有一个套接字socket与其相连。 2、客户端通过它的套接字发送http请求报文服务器通过套接字接收报文并解析。从存储器RAM或磁盘中检索出对象封装到响应报文中通过套接字向客户端发送。 3、服务器通知TCP断开连接实际是需要等到客户接受完响应报文后才会断开连接。 4、客户端接收完响应报文后TCP连接关闭。客户端从响应报文中提取出HTML响应文件然后循环检查报文中其他内部对象检查完成后把对应的资源通过显示器呈现给用户。
HTTP基本概念
HTTP是什么
HTTP 是超文本传输协议
超文本指传输的数据不仅包括文本还包括图片、音频、视频超链接等。
协议是指双方或多方相互约定好大家都需要遵守的规则叫协议。
传输传输说明Http是传输协议。HTTP 协议是一个“双向协议”。数据虽然是在 A 和 B 之间传输但并没有限制只有 A 和 B 这两个角色允许中间有“中转”或者“接力”。
HTTP协议就是指客户端服务端和服务端之间通信时发送的数据需要遵守的规则叫HTTP协议。
常见状态码
1xx状态码临时响应。表示临时响应并需要请求者继续执行操作的状态代码。
100继续。请求者应当继续发起请求。 服务器返回此代码表示已收到请求的第一部分正在等待其余部分。
101切换协议。 请求者已要求服务器切换协议服务器已确认并准备切换。
2xx状态码操作成功。200 OK
200成功。服务器已成功处理了请求。 通常这表示服务器提供了请求的网页。
201已创建。请求成功并且服务器创建了新的资源。
202已接受。服务器已接受请求但尚未处理。
203非授权信息。服务器已成功处理了请求但返回的信息可能来自另一来源。
204无内容。服务器成功处理了请求但没有返回任何内容。
205重置内容。服务器成功处理了请求但没有返回任何内容。但是与204响应不同返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后立即重置表单以便用户能够轻松地开始另一次输入。
206部分内容。服务器成功处理了部分 GET 请求。
3xx状态码重定向。表示要完成请求需要进一步操作。
300多种选择。针对请求服务器可执行多种操作。服务器可根据请求者选择一项操作或提供操作列表供请求者选择。
301永久重定向。请求的网页已永久移动到新位置。 服务器返回此响应时会自动将请求者转到新位置。
302临时重定向。服务器目前从不同位置的网页响应请求但请求者应继续使用原有位置来进行以后的请求。
303查看其他位置。请求者应当对不同的位置使用单独的 GET 请求来检索响应时服务器返回此代码。
304未修改。自从上次请求后请求的网页未修改过。 服务器返回此响应时不会返回网页内容。
305使用代理。请求者只能使用代理访问请求的网页。 如果服务器返回此响应还表示请求者应使用代理。
//306切换代理已废弃
307临时重定向 服务器目前从不同位置的网页响应请求但请求者应继续使用原有位置来进行以后的请求。
和302的唯一区别307可以确保请求方法和消息主体不会发生变化。如果使用302响应状态码一些旧客户端会错误地将请求方法转换为GET。
4xx状态码客户端错误。400 Bad Request401 Unauthorized403 Forbidden404 Not Found
400错误请求。服务器不理解请求的语法。
401未授权。请求要求身份验证。 对于需要登录的网页服务器可能返回此响应。
//402未付费没实现
403禁止。服务器拒绝请求。
404未找到。服务器找不到请求的网页。
405方法禁用。禁用请求中指定的方法。
406不接受。无法使用请求的内容特性响应请求的网页。
407需要代理授权。此状态代码与 401未授权类似但指定请求者应当授权使用代理。
408请求超时。服务器等候请求时发生超时。
409冲突。 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410已删除。如果请求的资源已永久删除服务器就会返回此响应。
411需要有效长度 服务器不接受不含有效内容长度标头字段的请求。
412未满足前提条件 服务器未满足请求者在请求中设置的其中一个前提条件。
413请求实体过大 服务器无法处理请求因为请求实体过大超出服务器的处理能力。
414请求的 URI 过长 请求的 URI通常为网址过长服务器无法处理。
415不支持的媒体类型 请求的格式不受请求页面的支持。
416请求范围不符合要求 如果页面无法提供请求的范围则服务器会返回此状态代码。
417未满足期望值 服务器未满足”期望”请求标头字段的要求。 400系列的错误信息都是“用户不友好”的。在古老的互联网时代当用户请求被拒绝时返回一个简短的代表错误原因的数字是一种节省流量、节省服务器端和客户端CPU资源的行为。
但是随着互联网的发展最佳的实践是当用户的请求被拒绝时网站服务器端应当重定向到一个合理的引流点。
例如用户请求的资源不存在404可以重定向到网站首页、或者推荐其他内容用户请求未授权内容403可以重定向到不需授权的内容用户请求收费的内容但未付费402可以重定向到付费页面。
5xx状态码服务端错误。500服务器内部错误501服务不可用
500服务器内部错误。服务器遇到错误无法完成请求。
501尚未实施。服务器不具备完成请求的功能。 例如服务器无法识别请求方法时可能会返回此代码。
502错误网关。服务器作为网关或代理从上游服务器收到无效响应。
503服务不可。服务器目前无法使用由于超载或停机维护。 通常这只是暂时状态。
504网关超时。服务器作为网关或代理但是没有及时从上游服务器收到请求。
505HTTP 版本不受支持。服务器不支持请求中所用的 HTTP 协议版本。
常见字段
Host 字段客户端发送请求时用来指定服务器的域名。
Connection 字段最常用于客户端要求服务器使用 TCP 持久连接以便其他请求复用。 Content-Length 字段服务器在返回数据时会有 Content-Length 字段表明本次回应的数据长度。
Content-Length: 1000 本次服务器回应的数据长度是 1000 个字节
Content-Type 字段服务器返回的数据是什么格式。
Content-Type: text/html; charsetutf-8
Content-Encoding 字段服务器返回的数据使用了什么压缩格式
Content-Encoding: gzip
HTTP1.1特性
简单基本的报文格式就是headerbody头部信息也是key-value的形式易于理解。
灵活和易拓展HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死都允许开发人员自定义和扩充。
应用广泛和跨平台从台式机的浏览器到手机上的各种 APP从看新闻、刷贴吧到购物、理财、吃鸡HTTP 的应用遍地开花同时天然具有跨平台的优越性。
无状态缺点
好处是服务器不会去记忆 HTTP 的状态所以不需要额外的资源来记录状态信息这能减轻服务器的负担能够把更多的 CPU 和内存用来对外提供服务。
坏处是服务器没有记忆能力对于同一个用户的不同操作都要问一遍身份信息。可以通过cookie解决。
明文传输缺点
在传输过程中的信息是可方便阅读的。但是不安全。
不安全缺点明文传输不验证通信方的身份无法证明报文的完整性可能被篡改。
如何优化HTTP 尽量避免发送 HTTP 请求 通过缓存 在需要发送 HTTP 请求时考虑如何减少请求次数 减少重定向请求次数 重定向的工作交由代理服务器完成就能减少 HTTP 请求次数了 合并请求 把多个访问小文件的请求合并成一个大的请求虽然传输的总资源还是一样但是减少请求也就意味着减少了重复发送的 HTTP 头部。 但是这样的合并请求会带来新的问题当大资源中的某一个小资源发生变化后客户端必须重新下载整个完整的大资源文件这显然带来了额外的网络消耗。 延迟发送请求 请求网页的时候没必要把全部资源都获取到而是只获取当前用户所看到的页面资源当用户向下滑动页面的时候再向服务器获取接下来的资源这样就达到了延迟发送请求的效果。 减少服务器的 HTTP 响应的数据大小 考虑对响应的资源进行压缩这样就可以减少响应的数据大小从而提高网络传输的效率。
HTTP 缓存技术
对于一些具有重复性的HTTP请求比如每次请求得到的数据是一样的就可以把这对请求-响应的数据都缓存到本地下次就可以直接读取本地的数据不用再获得服务器的响应了从而提高性能。
强制缓存
只要浏览器判断缓存没有过期就直接使用浏览器的本地缓存。决定是否使用缓存的主动性在于浏览器这边。
利用两个HTTP响应头部字段实现的Cache-Control 是一个相对时间 Expires是一个绝对时间都用来表示资源在客户端缓存的有效期。
优先用Cache-Control。1.当浏览器第一次请求访问服务器资源时服务器会在返回这个资源的同时在 Response 头部加上 Cache-ControlCache-Control 中设置了过期时间大小
2.浏览器再次请求访问服务器中的该资源时会先通过请求资源的时间与 Cache-Control 中设置的过期时间大小来计算出该资源是否过期如果没有则使用该缓存否则重新请求服务器
3.服务器再次收到请求后会再次更新 Response 头部的 Cache-Control。
协商缓存
当我们在浏览器使用开发者工具的时候你可能会看到过某些请求的响应码是 304这个是告诉浏览器可以使用本地缓存的资源通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。
协商缓存就是与服务端协商之后通过协商结果来判断是否使用本地缓存。
响应头部中 Etag唯一标识响应资源
请求头部中的 If-None-Match当资源过期时浏览器发现响应头里有 Etag则再次向服务器发起请求时会将请求头If-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对如果资源没有变化返回 304如果资源变化了返回 200。使用 ETag 字段实现的协商缓存的过程如下1.当浏览器第一次请求访问服务器资源时服务器会在返回这个资源的同时在 Response 头部加上 ETag 唯一标识这个唯一标识的值是根据当前请求的资源生成的
2.当浏览器再次请求访问服务器中的该资源时首先会先检查强制缓存是否过期如果没有过期则直接使用本地缓存如果缓存过期了会在 Request 头部加上 If-None-Match 字段该字段的值就是 ETag 唯一标识
3.服务器再次收到请求后会根据请求中的 If-None-Match 值与当前请求的资源生成的唯一标识进行比较如果值相等则返回 304 Not Modified不会返回资源如果不相等则返回 200 状态码和返回资源并在 Response 头部加上新的 ETag 唯一标识
4.如果浏览器收到 304 的请求响应状态码则会从本地缓存中加载资源否则更新资源。
GET与POST的区别
GET请求 浏览器地址栏中的地址是action 属性[?请求参数] 请求参数的格式是namevaluenamevalue POST请求 GET一般用于从服务器获取资源而POST一般用于表单提交有可能改变服务器上的资源 请求形式上GET请求的数据附在URL之后POST请求的数据在请求体中 安全性GET请求可被缓存、收藏、保留到历史记录且其请求数据明文出现在URL中。POST的参数不会被保存安全性相对较高 GET只允许ASCII字符因为URL只支持ASCII字符POST对数据类型没有要求也允许二进制数据 GET的长度有限制操作系统或者浏览器而POST数据大小无限制 GET是幂等的即读取同一个资源总是得到相同的数据POST不是幂等的
因为get是只读操作无论操作多少次服务器上的数据都是安全的且每次的结果都是相同的。可以对GET请求的数据做缓存这个缓存可以做到浏览器本身上也可以做到代理上如nginx而且在浏览器中GET请求可以保存为书签。
POST 因为是「新增或提交数据」的操作会修改服务器上的资源所以是不安全的且多次提交数据就会创建多个资源所以不是幂等的。所以浏览器一般不会缓存 POST 请求也不能把 POST 请求保存为书签。
响应的HTTP协议格式 HTTP/1.1的性能如何
基于TCP/IP使用请求-应答通信模式所以关键在于这两点。
1、长连接不需要每次发送请求都TCP连接只要任意一端没有明确提出断开连接则保持 TCP 连接状态。如果超过一定时间没有任何数据交互服务器回主动断开
2、管道网络传输在长连接基础上同一个TCp连接可以发送多个请求不需要等上一个请求回来就可以发送第二个减少整体响应时间。服务器必须按照接收请求的顺序发送对这些管道化请求的响应。有这个但是浏览器都不支持基本
3、队头阻塞顺序发送的请求由于某种原因阻塞了后面排队的请求也同样阻塞。
HTTP1.1/2/3
HTTP/0.9 仅支持GET请求不支持请求头
HTTP/1.0 默认短连接一次请求建议一次TCP连接请求完就断开支持GET、POST、HEAD请求
HTTP/1.1支持PUT、DELETE、PATCH等六种请求 增加host头支持虚拟主机支持断点续传功能 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。 支持管道pipeline网络传输只要第一个请求发出去了不必等其回来就可以发第二个请求出去可以减少整体的响应时间。
存在性能瓶颈 请求 / 响应头部Header未经压缩就发送首部信息越多延迟越大。只能压缩 Body 的部分 发送冗长的首部。每次互相发送相同的首部造成的浪费较多 服务器是按请求的顺序响应的如果服务器响应慢会招致客户端一直请求不到数据也就是队头阻塞 没有请求优先级控制 请求只能从客户端开始服务器只能被动响应。
HTTP/2.0 是基于 HTTPS的
相比http/1.1性能上的改进 头部压缩 如果你同时发出多个请求他们的头是一样的或是相似的那么协议会帮你消除重复的部分。 这就是所谓的 HPACK 算法在客户端和服务器同时维护一张头信息表所有字段都会存入这个表生成一个索引号以后就不发送同样字段了只发送索引号这样就提高速度了。 解析基于二进制格式 HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文而是全面采用了二进制格式头信息和数据体都是二进制并且统称为帧frame头信息帧Headers Frame和数据帧Data Frame。 数据流
HTTP/2 的数据包不是按顺序发送的同一个连接里面连续的数据包可能属于不同的回应。因此必须要对数据包做标记指出它属于哪个回应。 多路复用
HTTP/2 是可以在一个连接中并发多个请求或回应而不用按照顺序一一对应。移除了 HTTP/1.1 中的串行请求不需要排队等待也就不会再出现「队头阻塞」问题降低了延迟大幅度提高了连接的利用率。
在一个 TCP 连接里服务器收到了客户端 A 和 B 的两个请求如果发现 A 处理过程非常耗时于是就回应 A 请求已经处理好的部分接着回应 B 请求完成后再回应A请求剩下的部分。 服务器主动推送相关资源一个请求全部推送
HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式服务端不再是被动地响应可以主动向客户端发送消息。
缺陷
HTTP/2 通过 Stream 的并发能力解决了 HTTP/1 队头阻塞的问题看似很完美了但是 HTTP/2 还是存在“队头阻塞”的问题只不过问题不是在 HTTP 这一层面而是在 TCP 这一层。
HTTP/2 是基于 TCP 协议来传输数据的TCP 是字节流协议TCP 层必须保证收到的字节数据是完整且连续的这样内核才会将缓冲区里的数据返回给 HTTP 应用那么当「前 1 个字节数据」没有到达时后收到的字节数据只能存放在内核缓冲区里只有等到这 1 个字节数据到达时HTTP/2 应用层才能从内核中拿到数据这就是 HTTP/2 队头阻塞问题。
一旦发生了丢包现象就会触发 TCP 的重传机制这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。
HTTP/3.0
HTTP/1.1 和 HTTP/2 都有队头阻塞的问题 HTTP/1.1 中的管道 pipeline虽然解决了请求的队头阻塞但是没有解决响应的队头阻塞因为服务端需要按顺序响应收到的请求如果服务端处理某个请求消耗的时间比较长那么只能等响应完这个请求后 才能处理下一个请求这属于 HTTP 层队头阻塞。 HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 但是一旦发生丢包就会阻塞住所有的 HTTP 请求这属于 TCP 层队头阻塞。
HTTP/2 队头阻塞的问题是因为 TCP所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP
UDP 发送是不管顺序也不管丢包的所以不会出现像 HTTP/2 队头阻塞的问题。大家都知道 UDP 是不可靠传输的但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。
QUIC 是新协议对于很多网络设备根本不知道什么是 QUIC只会当做 UDP。所以HTTP/3 现在普及的进度非常的缓慢。
HTTP/1.1如何优化
尽量避免发送 HTTP 请求
在需要发送 HTTP 请求时考虑如何减少请求次数
减少服务器的 HTTP 响应的数据大小
1、尽量避免发送HTTP请求
将具有重复性的HTTP请求【请求-响应】数据缓存到本地。
2、减少HTTP请求次数
减少重定向请求次数重定向的工作交由代理服务器完成就能减少 HTTP 请求次数了
合并请求多个访问小文件的请求合并成一个大的请求。当大资源中的某一个小资源发生变化后客户端必须重新下载整个完整的大资源文 件这显然带来了额外的网络消耗。
延迟发送请求请求网页的时候没必要把全部资源都获取到而是只获取当前用户所看到的页面资源当用户向下滑动页面的时候再向服务器获取接下来的资源这样就达到了延迟发送请求的效果。
如何减少 HTTP 响应的数据大小
有损压缩和无损压缩 无损压缩
无损压缩是指资源经过压缩后信息不被破坏还能完全恢复到压缩前的原样适合用在文本文件、程序可执行文件、程序源代码。
gzip 就是比较常见的无损压缩。所以如果可以服务器应该选择压缩效率更高的 br 压缩算法。 有损压缩
解压的数据会与原始数据不同但是非常接近。
有损压缩主要将次要的数据舍弃牺牲一些质量来减少数据量、提高压缩比这种方法经常用于压缩多媒体数据比如音频、视频、图片。
HTTP和HTTPS
HTTPS在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议使得报文能够加密传输。TLS使用对称加密和非对称加密的混合加密方式来实现机密性。 端口不同HTTP使用的是80端口HTTPS使用443端口 HTTP超文本传输协议信息是明文传输HTTPS运行在SSL(Secure Socket Layer)之上添加了加密和认证机制更加安全 HTTP 连接建立相对简单 TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后还需进行 SSL/TLS 的握手过程才可进入加密报文传输。 HTTPS由于加密解密会带来更大的CPU和内存开销 HTTPS 协议需要向 CA证书权威机构申请数字证书(需要购买)来保证服务器的身份是可信的。
HTTP的风险和HTTPS的应对https解决了http啥问题
http由于是明文传输安全上存在三个风险
窃听风险比如通信链路上可以获取通信内容用户号容易没。
篡改风险比如强制植入垃圾广告视觉污染用户眼容易瞎。
冒充风险比如冒充淘宝网站用户钱容易没。
https很好地解决了上述的风险
信息加密交互信息无法被窃取。 混合加密实现
校验机制无法篡改通信内容篡改了就不能正常显示。 摘要算法实现完整性为数据生成指纹来校验。
身份证书确定是真的网址不能冒充。 把服务器公钥放入数字证书解决冒充的风险。
1.混合加密 HTTPs采用的是对称加密和非对称加密结合的混合加密方式。在通信建立前采用非对称加密交换会话密钥
在通信过程中全部使用对称加密的会话密钥的方式加密明文数据。- 对称加密加密和解密采用相同的密钥。如DES、RC2、RC4
- 非对称加密需要两个密钥公钥和私钥。两个密钥可以双向加解密。如RSA
【公钥加密私钥解密】保证内容传输的安全因为只有私钥才能解密公钥加密的内容。
【私钥加密公钥解密】保证消息不会冒充。因为私钥是不可泄漏的如果公钥能揭秘成功证明消息是持有私钥身份的人发送的。采用混合加密的原因对称加密只使用一个密钥运算速度快无法做到安全的交换非对称使用两个密钥公钥可以任意分发而私钥保密解决了密钥交换问题但是速度慢。所以综合两者。2.摘要算法数字签名
为了保证传输的内容不被篡改需要对内容计算出一个指纹同内容一起传输给对方。对方收到后会先对内容计算出一个指纹跟发来的指纹比较相同就说明内容没有被篡改。
使用摘要算法哈希函数来计算出内容的哈希值也就是指纹。哈希值是唯一的且无法通过哈希值推导出内容。摘要算法:MD5、SHA
通过哈希算法可以确保内容不会被篡改但是不能保证【内容哈希值】不会被中间人替换。
可以通过非对称加密的【私钥加密公钥解密】的方式来确认消息的身份。加密的是内容的哈希值。——数字签名保证消息来源的可靠性
发送者A用私钥进行签名接收者B用公钥验证签名。因为除A外没有人有私钥所以B相信签名是来自A。A不可抵赖B也不能伪造报文。
私钥由服务端保管服务端会向客户端颁发对应的公钥如果客户端收到的消息能被公钥解密就说明消息是由服务器发送的。3.数字证书
公钥可能被伪造通过数字证书的方式保证服务器公钥的身份解决冒充的风险。 数字证书认证机构--CA服务器把自己的公钥注册到CACA用自己的私钥将服务器的公钥做数字签名并颁发数字证书。数字证书 服务器的公钥CA的数字签名
客户端拿到服务器的数字证书后使用CA的公钥确认服务器的数字证书的真实性。从数字证书获取服务器公钥。
客户端使用公钥对报文加密后发送服务器用私钥对报文解密。
Https连接过程SSL握手
基本流程客户端向服务器索要并验证服务器的公钥。双方协商生产会话密钥。双方采用会话密钥进行加密通信。 客户端向服务器发起加密通信请求同时发送客户端支持的SSL/TLS协议版本支持的一套加密规则。 服务器从中选出一组加密算法与HASH算法并将自己的身份信息以数字证书的形式发回给客户端。证书里面包含了网站地址加密公钥用于非对称加密以及证书的颁发机构等信息证书中的私钥只能用于服务器端进行解密。 客户端收到回应后会先验证服务器的合法性包括证书是否过期CA 是否可靠发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”服务器证书上的域名是否和服务器的实际域名相匹配 如果证书受信任客户端会生成一个随机密钥用于对称算法并用服务器提供的公钥加密采用非对称算法对密钥加密使用Hash算法对握手消息进行摘要计算并对摘要使用之前产生的密钥加密对称算法将加密后的随机密钥和摘要一起发送给服务器 服务器使用自己的私钥解密得到对称加密的密钥用这个密钥解密出Hash摘要值并验证握手消息是否一致如果一致服务器使用对称加密的密钥加密握手消息发给客户端 客户端解密并验证摘要若一致则握手结束。之后的数据传送都使用对称加密的密钥进行加密
总结非对称加密算法用于在握手过程中加密生成的密码对称加密算法用于对真正传输的数据进行加密HASH算法摘要算法用于验证数据的完整性。数字签名保证消息来源的可靠性。
如何保证数据完整性
TLS 在实现上分为握手协议和记录协议两层 TLS 握手协议就是前面说的 TLS 四次握手的过程负责协商加密算法和生成对称密钥后续用此密钥来保护应用程序数据即 HTTP 数据 TLS 记录协议负责保护应用程序数据并验证其完整性和来源所以对 HTTP 数据加密是使用记录协议
TLS 记录协议主要负责消息HTTP 数据的压缩加密及数据的认证。 首先消息被分割成多个较短的消息片段,然后分别对每个片段进行压缩。 接下来经过压缩的片段会被加上消息认证码MAC 值这个是通过哈希算法生成的这是为了保证完整性并进行数据的认证。通过附加消息认证码的 MAC 值可以识别出篡改。与此同时为了防止重放攻击在计算消息认证码时还加上了片段的编码。 再接下来经过压缩的片段再加上消息认证码会一起通过对称密码进行加密。 最后上述经过加密的数据再加上报头由数据类型、版本号、压缩后的长度组成的就是最终的报文数据。
记录协议完成后最终的报文数据将传递到传输控制协议 (TCP) 层进行传输。
网站如何自动切换到 HTTPS
一种是原始的302跳转临时重定向服务器把所有的HTTp流量跳转到HTTPS。但这样有一个漏洞就是第一次访问站点的时候如果是 HTTP 就有可能被中间人劫持很可能都没到 302 跳转的时候就被劫持了。 解决方法是引入HSTS机制 用户的浏览器一旦得到了 HSTS 的信息下次再访问站点的时候客户端浏览器就会强制使用 HTTPS。 无论你在地址栏里输入什么都会以 HTTPS 访问。
HSTS 本身也有缺陷假如用户的浏览器从未访问过这个站点那也就不会得到 HSTS 响应头 这个时候依然会有被劫持风险 但相比每次都进行服务端跳转的机制已经好了不少。
针对 HSTS 的这个缺陷主流的浏览器也提供了一些解决方案比如把一些大流量并且已知支持 HSTS 的站点预先内置到浏览器中这样就更大程度的完善了 HTTPS 的安全机制。
HTTPS 一定安全可靠吗
客户端通过浏览器向服务端发起 HTTPS 请求时被「假基站」转发到了一个「中间人服务器」于是客户端是和「中间人服务器」完成了 TLS 握手然后这个「中间人服务器」再与真正的服务端完成 TLS 握手。
从客户端的角度看其实并不知道网络中存在中间人服务器这个角色。那么中间人就可以解开浏览器发起的 HTTPS 请求里的数据也可以解开服务端响应给浏览器的 HTTPS 响应数据。相当于中间人能够 “偷看” 浏览器与服务端之间的 HTTPS 请求和响应的数据。
但是要发生这种场景是有前提的前提是用户点击接受了中间人服务器的证书。
中间人服务器与客户端在 TLS 握手过程中实际上发送了自己伪造的证书给浏览器而这个伪造的证书是能被浏览器客户端识别出是非法的于是就会提醒用户该证书存在问题。
如果用户执意点击「继续浏览此网站」相当于用户接受了中间人伪造的证书那么后续整个 HTTPS 通信都能被中间人监听了。
这其实并不能说 HTTPS 不够安全毕竟浏览器都已经提示证书有问题了。HTTPS 协议本身到目前为止还是没有任何漏洞的即使你成功进行中间人攻击本质上是利用了客户端的漏洞用户点击继续访问或者被恶意导入伪造的根证书并不是 HTTPS 不够安全
中间人攻击
HTTPS连接的时候怎么确定收到的包是服务器发来的
SSL劫持攻击
攻击者在传输过程中伪造服务器的证书将服务器的公钥替换成自己的公钥
但是对于客户端来说如果中间人伪造了证书在校验证书过程中会提示证书错误。SSL剥离攻击
中间人和服务器之间仍然保持HTTPS服务器
之后将HTTPS范文替换为HTTP返回给浏览器。
如何避免被中间人抓取数据
要保证自己电脑的安全不要被病毒乘虚而入被恶意导入伪造的根证书。而且也不要点击任何证书非法的网站这样 HTTPS 数据就不会被中间人截取到了。
当然我们还可以通过 HTTPS 双向认证来避免这种问题。
一般我们的 HTTPS 是单向认证客户端只会验证了服务端的身份但是服务端并不会验证客户端的身份。
如果用了双向认证方式不仅客户端会验证服务端的身份而且服务端也会验证客户端的身份。服务端一旦验证到请求自己的客户端为不可信任的服务端就拒绝继续通信客户端如果发现服务端为不可信任的那么也中止通信。
https RSA握手解析 Ecdhe握手解析的区别
RSA 和 ECDHE 握手过程的区别RSA 密钥协商算法「不支持」前向保密ECDHE 密钥协商算法「支持」前向保密
使用了 RSA 密钥协商算法TLS 完成四次握手后才能进行应用数据传输而对于 ECDHE 算法客户端可以不用等服务端的最后一次 TLS 握手就可以提前发出加密的 HTTP 数据节省了一个消息的往返时间这个是 RFC 文档规定的具体原因文档没有说明所以这点我也不太明白
使用 ECDHE 在 TLS 第 2 次握手中会出现服务器端发出的「Server Key Exchange」消息而 RSA 握手过程没有该消息http如何优化
对于硬件优化的方向因为 HTTPS 是属于计算密集型应该选择计算力更强的 CPU而且最好选择支持 AES-NI 特性的 CPU这个特性可以在硬件级别优化 AES 对称加密算法加快应用数据的加解密。对于软件优化的方向如果可以把软件升级成较新的版本比如将 Linux 内核 2.X 升级成 4.X将 openssl 1.0.1 升级到 1.1.1因为新版本的软件不仅会提供新的特性而且还会修复老版本的问题。对于协议优化的方向密钥交换算法应该选择 ECDHE 算法而不用 RSA 算法因为 ECDHE 算法具备前向安全性而且客户端可以在第三次握手之后就发送加密应用数据节省了 1 RTT。
将 TLS1.2 升级 TLS1.3因为 TLS1.3 的握手过程只需要 1 RTT而且安全性更强。
对于证书优化的方向服务器应该选用 ECDSA 证书而非 RSA 证书因为在相同安全级别下ECC 的密钥长度比 RSA 短很多这样可以提高证书传输的效率
服务器应该开启 OCSP Stapling 功能由服务器预先获得 OCSP 的响应并把响应结果缓存起来这样 TLS 握手的时候就不用再访问 CA 服务器减少了网络通信的开销提高了证书验证的效率
对于重连 HTTPS 时我们可以使用一些技术让客户端和服务端使用上一次 HTTPS 连接使用的会话密钥直接恢复会话而不用再重新走完整的 TLS 握手过程。常见的会话重用技术有 Session ID 和 Session Ticket用了会话重用技术当再次重连 HTTPS 时只需要 1 RTT 就可以恢复会话。对于 TLS1.3 使用 Pre-shared Key 会话重用技术只需要 0 RTT 就可以恢复会话。这些会话重用技术虽然好用但是存在一定的安全风险它们不仅不具备前向安全而且有重放攻击的风险所以应当对会话密钥设定一个合理的过期时间。 websocket和http的区别 WebSocket是双向通信协议,模拟Socket协议,可以双向发送或接受信息。HTTP是单向的。 WebSocket是需要浏览器和服务器握手进行建立连接的。而http是浏览器发起向服务器的连接,服务器预先并不知道这个连接。 WebSocket在建立握手时,数据是通过HTTP传输的。但是建立之后,在真正传输时候是不需要HTTP协议的。”
RPC协议
RPCRemote Procedure Call远程过程调用它本身并不是一个具体的协议而是一种调用方式。一种通过网络从远程计算机上请求服务而不需要了解底层网络技术的协议。
RPC协议的主要目的是做到不同服务间调用方法像同一服务间调用本地方法一样。
如果仅仅是远程调用还不算是RPC因为RPC强调的是过程调用调用的过程对用户而言是应该是透明的用户不应该关心调用的细节可以像调用本地服务一样调用远程服务。所以RPC一定要对调用的过程进行封装。
RPC的四个过程
1建立通信 2服务寻址 3网络传输 4服务调用
为什么要使用RPC
1服务化/微服务 2分布式系统架构 3服务可重用 4系统间交互调用
现在比较流行的RPC框架都会采用TCP作为底层传输协议广泛应用在大规模分布式应用中。
框架有哪些
RMI远程方法调用JAVA自带的远程方法调用工具
Dubbo阿里开源的基于TCP的RPC框架基于Netty的高性能RPC框架
使用场景 1内部子系统较多。
众多的内部子系统是驱动采用RPC架构的原因之一订单系统支付系统商品系统用户系统............ 每个可独立单独布署。RPC主要使用在大型企业内部子系统之间的调用。因为大型企业里面系统繁多业务线复杂而且效率优势非常重要的一块这个时候RPC的优势就比较明显了。基于HTTP协议的接口包括Webservice等主要作为对外接口服务。
2接口访问量巨大。 RPC基于长连接。要求满足支持 负载均衡“熔断降级” 一类面向服务的高级特性。
3接口非常多 “服务发现”。
RPC和HTTP的区别
1、服务发现
HTTP中通过域名解析可以得到IP地址和端口号
RPC中会有专门的中间服务去保存服务名和IP信息比如consul或者etcd甚至是redis。想要访问某个服务就去这些中间服务去获得IP和端口信息。
2.底层连接形式
HTTP1.1协议为例其默认在建立底层TCP连接之后会一直保持这个连接keep alive之后的请求和响应都会复用这条连接。
RPC协议也是通过建立TCP长链接进行数据交互但不同的地方在于RPC协议一般还会再建个连接池在请求量大的时候建立多条连接放在池内。
由于连接池有利于提升网络请求性能所以不少编程语言的网络库里都会给HTTP加个连接池比如go就是这么干的。
3.传输的内容
RPC并没有规定数据传输格式这个格式可以任意指定不同的RPC协议数据格式不一定相同HTTP规定了网络传输的请求格式、响应格式。
Http中还定义了资源定位的路径RPC中并不需要。
4、RPC需要满足像调用本地服务一样调用远程服务也就是对调用过程在API层面进行封装Http协议没有这样的要求因此请求、响应等细节需要我们自己去实现。
上面说的HTTP其实特指的是现在主流使用的HTTP1.1HTTP2在前者的基础上做了很多改进所以性能可能比很多RPC协议还要好。
由于 HTTP2 是2015年出来的。那时候很多公司内部的RPC协议都已经跑了好些年了基于历史原因一般也没必要去换了。
5、优缺点 1RPC方式更加透明对用户更方便。Http方式更灵活没有规定API和语言跨语言、跨平台。 2RPC方式需要在API层面进行封装限制了开发的语言环境。
3RPC主要使用在大型企业内部子系统之间的调用HTTP协议主要作为对外接口服务。
4如果对效率要求更高并且开发过程使用统一的技术栈那么用RPC还是不错的。如果需要更加灵活跨语言、跨平台显然http更合适。
RPC和MQ的区别和关联
1.在架构上RPC和MQ的差异点是MQ有一个中间结点Message Queue可以把消息存储。
2.同步调用对于要立即等待返回处理结果的场景RPC是首选。
3.MQ 的使用一方面是基于性能的考虑比如服务端不能快速的响应客户端或客户端也不要求实时响应需要在队列里缓存。另外一方面它更侧重数据的传输因此方式更加多样化除了点对点外还有订阅发布等功能。
4.而且随着业务增长有的处理端处理量会成为瓶颈会进行同步调用改造为异步调用这个时候可以考虑使用MQ。
什么是RIP (Routing Information Protocol, 距离矢量路由协议)? 算法是什么
每个路由器维护一张表记录该路由器到其它网络的”跳数“路由器到与其直接连接的网络的跳数是1每多经过一个路由器跳数就加1更新该表时和相邻路由器交换路由信息路由器允许一个路径最多包含15个路由器如果跳数为16则不可达。交付数据报时优先选取距离最短的路径。
PSRIP是应用层协议RIP 协议到底是网络层协议还是应用层的协议 - 知乎
优缺点
实现简单开销小 随着网络规模扩大开销也会增大 最大距离为15限制了网络的规模 当网络出现故障时要经过较长的时间才能将此信息传递到所有路由器 /details
IP地址的分类 路由器仅根据网络号net-id来转发分组当分组到达目的网络的路由器之后再按照主机号host-id将分组交付给主机同一网络上的所有主机的网络号相同。
什么叫划分子网
从主机号host-id借用若干个比特作为子网号subnet-id子网掩码网络号和子网号都为1主机号为0数据报仍然先按照网络号找到目的网络发送到路由器路由器再按照网络号和子网号找到目的子网将子网掩码与目标地址逐比特与操作若结果为某个子网的网络地址则送到该子网。
什么是ARP协议 (Address Resolution Protocol)
ARP协议完成了IP地址与物理地址的映射。每一个主机都设有一个 ARP 高速缓存里面有所在的局域网上的各主机和路由器的 IP 地址到硬件地址的映射表。当源主机要发送数据包到目的主机时会先检查自己的ARP高速缓存中有没有目的主机的MAC地址如果有就直接将数据包发到这个MAC地址如果没有就向所在的局域网发起一个ARP请求的广播包在发送自己的 ARP 请求时同时会带上自己的 IP 地址到硬件地址的映射收到请求的主机检查自己的IP地址和目的主机的IP地址是否一致如果一致则先保存源主机的映射到自己的ARP缓存然后给源主机发送一个ARP响应数据包。源主机收到响应数据包之后先添加目的主机的IP地址与MAC地址的映射再进行数据传送。如果源主机一直没有收到响应表示ARP查询失败。
如果所要找的主机和源主机不在同一个局域网上那么就要通过 ARP 找到一个位于本局域网上的某个路由器的硬件地址然后把分组发送给这个路由器让这个路由器把分组转发给下一个网络。剩下的工作就由下一个网络来做。
什么是NAT (Network Address Translation, 网络地址转换)
用于解决内网中的主机要和因特网上的主机通信。由NAT路由器将主机的本地IP地址转换为全球IP地址分为静态转换转换得到的全球IP地址固定不变和动态NAT转换。
参考 面试/笔试第一弹 —— 计算机网络面试问题集锦 什么时候选TCP、UDP TCP速率与窗口带宽RTT之间的关系
