物理层
决定以哪种物理信号进行0,1传输,负责光电信号、高低电压传递方式。集线器工作在物理层。以太网协议。
设备:电缆、双绞线、无线网(电磁微波)。
功能:实现0、1bit信号的传输。这些0、1信号就是计算机能够识别的数据。
数据链路层
数据链路层:决定了两个电脑之间的数据帧的传输和识别(如何传输信息,局域网)。交换机工作在数据链路层。
例如网卡设备的驱动,帧同步,冲突检测,数据差错校验等工作。
经物理层传输后,接收到信号010101010101比特流
看得懂吗?谁送的信号?送给谁?因此,我们需要有一个规定(协议)来说明怎么我们该怎么编制有用的信号,然后大家就照这个来。
以太网协议
以太网协议就是来解决上面问题的。他规定一个数据包(帧)应该包含以下内容:
地址:以太网帧中,目的地址与源地址这里都指的是 MAC 地址(Media Access Control Address)。每一个主机都有网卡接口,网卡会产生一个 MAC 地址,该地址由供应商代码和***组成(参考),长度是 48 位,所以这里的目的地址与源地址都是 6 个字节,也就是 48 个比特位。
数据质量:在以太网帧的最后,是一个 CRC 校验码,来校验数据是否异常。
向上交付时的协议:在中间,有一个两个字节的类型标识。这个类型字段有三种值,分别是 : IP、ARP、RARP,对应的是向上层交付时采用的协议(上一层怎么读懂我)。
问题:虽然有地址,但发出时是以广播的形式发出,即所有连着的计算机都可能收到信号,怎么办?另:如果A计算机要给B发消息,那A怎么知道B的地址呢?
广播与ARP协议
广播:计算机以广播的形式发出信号,所有连着的计算机都可能受到信号,这是接受到信号的计算机判断目的地址是不是自己。是,则接受;否,则丢弃。就像在广场上,有人大呼某个人的名字,你听到了,则判断如果是你,则回应,否则,就当没听见。
ARP协议:计算机 A 是如何知道计算机 B 的 MAC 地址的呢?这个时候就得由 ARP 协议这个家伙来解决了,不过 ARP 协议会涉及到IP地址,我们下面才会扯到IP地址。因此我们先放着,就当作是有这么一个 ARP 协议,通过它我们可以知道子网中其他计算机的 MAC 地址。
网络层
3、网络层:决定地址管理和路由选择(大范围的网路,广域网如何定位,如何传输)。路由器工作在网络层。
实际上,广播时只有同一个子网中的计算机能收到,而互联网实际上是由无数个子网组成的。
为什么要有子网? 这样划分很有好处,否则全世界无数的计算机都会收到数据包,光是判断这个数据包的工作量无法忍受。
进一步,怎么区分MAC地址是否为同一个子网?解决方案是使用IP协议。
IP
在 IP 协议里面需要有**源地址 IP **和 目标地址 IP:
- 源地址IP,即是客户端输出的 IP 地址;
- 目标地址,即通过 DNS 域名解析得到的 Web 服务器 IP。
因为 HTTP 是基于 TCP 传输的,所以在 IP 包头的协议号,要填写为 06
(十六进制),表示协议为 TCP协议。
IP协议定义的地址称为IP地址。目前有两种版本,一种是IPv4,另一种是IPv6,IPv6版本可以提供更多的地址。目前主要是IPv4
IP地址怎么帮我们找到一个设备(计算机)呢?实际上IP地址给出了计算机的两部分信息:1、网络部分,给出计算机所处的子网;2、主机部分计算机的主机地址。
那进一步这两个部分分别对应哪些二进制位数呢?实际上这两个部分所占的二进制位数并是不固定的。因为我们可以根据子网的规模合理分配IP地址。比如一个少于255台主机的子网主机部分只需占8位就够了,如果占了16位,则很多地址都不会被用到,这是极大的浪费。
那我怎么知道网络部分和主机部分分别占几位呢?解决方案是引入子网掩码,他也是32位二进制数,并规定网络部分全为1,主机部分全为0。比如,主机部分为8位时,则对应的子网掩码是:
11111111.11111111.11111111.00000000,即255.255.255.0。
有了子网掩码,就知道了哪些是网络部分,进而只需要把两个IP地址网络部分的网络部分对比,就知道是否在同一个子网中。
ARP协议
现在知道了IP协议,回头说ARP协议。之前说了他是用来得到同一个子网中目标计算机的MAC 地址,怎么实现呢?
ARP协议也是通过广播形式发送数据包给子网中所有计算机,数据包中含有目标计算机B的IP地址(不是MAC地址)。所有收到数据包的计算机会比较改地址和自己是否一致。如果一致,就回复给源计算机A自己的MAC地址(该地址唯一标志了主机的网卡接口)。否则丢弃该数据包。
有一个问题:其他计算机怎么知道你想要传数据还是想询问MAC地址?e解决方法:ARP协议中的数据包中在对方的MAC地址这一栏中,填的是一个特殊的MAC地址,其他计算机看到这个特殊的MAC地址就知道是想干嘛了。
那如果不是同一个子网,怎么发数据包给对方呢? 假如两台计算机的IP不是处于同一个子网之中,这个时候,我们就会把数据包发送给网关,然后让网关让我们进行转发传送。
两点传输 —— MAC
生成了 IP 头部之后,接下来网络包还需要在 IP 头部的前面加上 MAC 头部。
MAC 头部是以太网使用的头部,它包含了接收方和发送方的 MAC 地址等信息,用于两点之间的传输。
一般在 TCP/IP 通信里,MAC 包头的协议类型只使用:
0800
: IP 协议0806
: ARP 协议
MAC 发送方和接收方如何确认?
发送方的 MAC 地址获取就比较简单了,MAC 地址是在网卡生产时写入到 ROM 里的,只要将这个值读取出来写入到 MAC 头部就可以了。
接收方的 MAC 地址就有点复杂了,只要告诉以太网对方的 MAC 的地址,以太网就会帮我们把包发送过去,那么很显然这里应该填写对方的 MAC 地址。
所以先得搞清楚应该把包发给谁,这个只要查一下路由表就知道了。在路由表中找到相匹配的条目,然后把包发给 Gateway
列中的 IP 地址就可以了。
既然知道要发给谁,按如何获取对方的 MAC 地址呢?
不知道对方 MAC 地址?不知道就喊呗。
此时就需要 ARP
协议帮我们找到路由器的 MAC 地址。
ARP 协议会在以太网中以广播的形式,对以太网所有的设备喊出:“这个 IP 地址是谁的?请把你的 MAC 地址告诉我”。
然后就会有人回答:“这个 IP 地址是我的,我的 MAC 地址是 XXXX”。
如果对方和自己处于同一个子网中,那么通过上面的操作就可以得到对方的 MAC 地址。然后,我们将这个 MAC 地址写入 MAC 头部,MAC 头部就完成了。
好像每次都要广播获取,这不是很麻烦吗?
放心,在后续操作系统会把本次查询结果放到一块叫做 ARP 缓存的内存空间留着以后用,不过缓存的时间就几分钟。
也就是说,在发包时:
- 先查询 ARP 缓存,如果其中已经保存了对方的 MAC 地址,就不需要发送 ARP 查询,直接使用 ARP 缓存中的地址。
- 而当 ARP 缓存中不存在对方 MAC 地址时,则发送 ARP 广播查询。
传输层
传输层:保证网络之间数据稳定传输,tcp可靠,udp不可靠。
负责分割、组合数据,实现端到端的逻辑连接。数据在上三层是整体的,到了这一层开始被分割
经过前面几层,我们已经知道如何把数据从计算机A发给计算机B。而一台计算机中的应用程序众多,我们怎么知道数据给哪一个应用呢?
这个时候就需要用到传输层最常见的两大协议是:TCP 协议和 UDP 协议,两者最大的不同就是 TCP 提供可靠的传输,而 UDP 提供的是不可靠传输。
TCP
TCP报文
TCP 报文生成
TCP 协议里面会有两个端口,一个是浏览器监听的端口(通常是随机生成的),一个是 Web 服务器监听的端口(HTTP 默认端口号是 80
, HTTPS 默认端口号是 443
)。
在双方建立了连接后,TCP 报文中的数据部分就是存放 HTTP 头部 + 数据,组装好 TCP 报文之后,就需交给下面的网络层处理。
端口号 2^16个
TCP 报文头部的格式
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-J9waXkUB-1670228458066)(…/img/image-20220828171902263.png)]
1、首先,源端口号和IP和目标端口和IP号是不可少的,如果没有这两个端口号,数据就不知道应该发给哪个应用。
2、响应时间 ** 一方在响应时间内没有收到消息后 会超时重发**(意味着在网卡里面有备份 只有收到响应后才会删除备份)
传输数据的过程要求保证时间绝对一致(时间同步网)
3、还有一个重要的就是窗口大小。TCP 要做流量控制,通信双方各声明一个窗口(缓存大小),标识自己当前能够的处理能力,超大数据文件会导致其他传输断网(A向D一次性传输10G数据,比特流是连续的)。除了做流量控制以外,TCP还会做拥塞控制,即控制发送的速度。太大的数据包拆分 给其他的应用传输数据的时间 不让其他应用断网
http数据拆分
MTU
:一个网络包的最大长度,以太网中一般为1500
字节。MSS
:除去 IP 和 TCP 头部之后,一个网络包所能容纳的 TCP 数据的最大长度。
数据会被以 MSS
的长度为单位进行拆分,拆分出来的每一块数据都会被放进单独的网络包中。也就是在每个被拆分的数据加上 TCP 头信息,然后交给 IP 模块来发送数据。
4、接下来有包的序号,这个是为了解决包乱序的问题。接收方收到全部数据后再重新组装 但是分包发送 有的包可能会超时重发,或者什么虚电路 所以顺序不一定 所有要有序号来标明
接收方只要收到发送方所有的数据后才能根据序号组装 所有发送方发送要有一个数据总大小
5、还有应该有的是确认号,目的是确认发出去对方是否有收到。如果没有收到就应该重新发送,直到送达,这个是为了解决不丢包的问题。
6、接下来还有一些状态位。例如 SYN
是发起一个连接,ACK
是回复,RST
是重新连接,FIN
是结束连接等。TCP 是面向连接的,因而双方要维护连接的状态,这些带状态位的包的发送,会引起双方的状态变更。
CRC校验原理:
其根本思想就是先在要发送的帧后面附加一个数(这个就是用来校验的校验码,但要注意,这里的数也是二进制序列的,下同),生成一个新帧发送给接收端。当然,这个附加的数不是随意的,它要使所生成的新帧能与发送端和接收端共同选定的某个特定数整除(注意,这里不是直接采用二进制除法,而是采用一种称之为“模2除法”)。到达接收端后,再把接收到的新帧除以(同样采用“模2除法”)这个选定的除数。因为在发送端发送数据帧之前就已通过附加一个数,做了“去余”处理(也就已经能整除了),所以结果应该是没有余数。如果有余数,则表明该帧在传输过程中出现了差错。
保证稳定传输:
超时重传
流量控制
拥塞控制
滑动窗口
解决了每次数据包都得等回应传输完毕的弊端,
比如有100个数据,不是每次一个一个发并且等待响应,这样就很费时间;现在我们在一个窗口中发送10个数据之后再进行响应接收,然后再发送10个,这样就快了10倍
解决了-----(发送-----响应时间——下一个发送)这一阶段的时间
三次握手,四次挥手
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QWf74gDD-1670228458066)(…/img/image-20221005173356293.png)]
syn用于同步,ack用于应答
SYN 包(synchronize) TCP连接的第一个包,非常小的一种数据包。
ACK 在数据通信传输中,接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误。
2、TCP三次握手 过程
( 1 )首先Client向Server发送连接:SYN = 1(同步请求报文段), seq=x;
因为要建立连接,所以SYN=1;又因为TCP规定SYN=1时不能携带数据,但要消耗一个序号, 所以Client随机选取一个初始序号seq=x。(因为并没有响应动作,所以这里没ACK什么事,我们就认为ACK=0吧)
发送后Client进入syn_sent状态,表示客户端等待服务器的回复。
(2)Server收到请求后 再向Client发送确认:SYN=1, ACK=1, seq=y, ack=x+1;
因为Server建立连接后做出了响应,所以SYN=1, ACK=1。因为TCP规定SYN=1时不能携带数据,但要消耗一个序号, 所以Server随机选取一个初始序号seq=y。又因为Server到 x为止的所有数据都已正确收到了,且Server告诉Client:我期待你下次给我发送包的初始序号(seq)是x+1,所以ack=x+1。
发送后服务器进入syn_rcvd,表示服务器已经收到Client的连接请求,等待Client的确认。
(3)Client收到确认后还需再次发送确认,同时携带要发送给Server的数据:ACK=1, seq=x+1, ack= y+1;连接建立
因为有 响应 动作,所以ACK=1(因为要携带发送的数据,所以这儿没SYN什么事)。因为(2)中Server 已经告诉了这次它想收到包的初始序列号是x+1,所以初始序号为seq=x+1。又因为Client到 y为止的所有数据都已正确收到了,准备接收序列号为y+1的包,所以ack=y+1。
Server收到后,这个TCP连接就进入Established状态,就可以发起http请求了。
四次挥手过程
第一次挥手:客户端A数据传输完毕需要断开连接,A的应用进程向其TCP发出连接释放报文段(FIN = 1,序号seq = u),并停止再发送数据,主动关闭TCP连接,进入FIN-WAIT-1状态,等待B的确认。
第二次挥手:B收到连接释放报文段后即发出确认报文段(ACK=1,确认号ack=u+1,序号seq=v),B进入CLOSE-WAIT关闭等待状态,此时的TCP处于半关闭状态,A到B的连接释放。而A收到B的确认后,进入FIN-WAIT-2状态,等待B发出的连接释放报文段。
第三次挥手:当B数据传输完毕后,B发出连接释放报文段(FIN = 1,ACK = 1,序号seq = w,确认号ack=u+1),B进入LAST-ACK(最后确认)状态,等待A 的最后确认。
第四次挥手:A收到B的连接释放报文段后,对此发出确认报文段(ACK = 1,seq=u+1,ack=w+1),A进入TIME-WAIT(时间等待)状态。此时TCP未释放掉,需要经过时间等待计时器设置的时间2MSL(两次请求报文段时间)后,A才进入CLOSE状态。
为什么要进行三次握手呢(两次确认)?
这主要是为了防止已失效的请求连接报文忽然又传送到了,从而产生错误。
假定A向B发送一个连接请求,由于一些原因,导致A发出的连接请求在一个网络节点逗留了比较多的时间。此时A会将此连接请求作为无效处理 又重新向B发起了一次新的连接请求,B正常收到此连接请求后建立了连接,数据传输完成后释放了连接。如果此时A发出的第一次请求又到达了B,B会以为A又发起了一次连接请求,如果是两次握手:此时连接就建立了,B会一直等待A发送数据,从而白白浪费B的资源。 如果是三次握手:由于A没有发起连接请求,也就不会理会B的连接响应,B没有收到A的确认连接,就会关闭掉本次连接
如果已经建立了连接,但是客户端突然出现故障了怎么办?
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
为什么需要四次挥手?
因为TCP是一个全双工协议,必须单独拆除每一条信道。4次挥手的目的是终止数据传输,并回收资源,此时两个端点两个方向的序列号已经没有了任何关系,必须等待两方向都没有数据传输时才能拆除虚链路,不像初始化时那么简单,发现SYN标志就初始化一个序列号并确认SYN的序列号。因此必须单独分别在一个方向上终止该方向的数据传输。
TCP和UDP的区别
UDP:
1、UDP面向报文,无需建立连接,不可靠,数量小,高层就解决差错重传,无需拥塞控制,网络拥堵也不影响效率
2、支持音频、视频传输
3、检查和检验UDP包头和数据和伪首部
4、分组开销小(头部8个字节),提供最大努力交付,且无序
TCP:
1、TCP是面向字节流,有连接的端到端的传输层协议
2、TCP提供稳定、可靠的交付服务,保证传送的数据无差错、不丢失、不重复且有序
3、支持数据传输
4、校验和检验TCP报头和数据、伪首部(IP数据报的一部分)
TCP & UDP
TCP/IP中有两个具有代表性的传输层协议,分别是TCP和UDP。
UDP:用户数据报协议,他是无连接的协议,不需要在发送数据前进行三次握
手建立连接,支持一对一(单播) ,一对多(多播) ,多对一(广播),是面
向报文的,在网络不好的情况下可能会丢包适用于实时性要求高的场景(电话
会议,直播,QQ语音, QQ视频)
为什么适用这些呢?答:是因为UDP传输速率高,处理速度快,虽然是无连接
不可靠的,但是对于直播,语音这些偶尔丢失一-两个数据包不会对接收结果产
生太大影响。
注解: UDP面向报文就是说无论应用层交给UDP多长的报文, UDP都照常发
送,不合并不拆分, - -次发送一个报文。
TCP:传输控制协议,保证数据不丢失且不乱序。因此自发送数据前建立可靠
连接,即三次握手。
三次握手的流程:目的就是双方确认自己与对方的发送与接收是正常的。
会话层
负责建立、维护、控制会话,区分不同的会话,以及提供单工(Simplex)、半双工(Halfduplex)、全双工(Full duplex)三种通信模式的服务。
表示层
负责数据的编码、转化,确保应用层的正常工作。
这一层,是将我们看到的界面与二进制间互相转化的地方,
就是我们的语言与机器语言间的转化。
数据的压缩、解压,加密、解密都发生在这一层。
这一层根据不同的应用目的将数据处理为不同的格式,表现出来就是我们看到的各种各样的文件扩展名。
应用层
几乎都基于Tcp的可靠、准确传输
就是应用程序。这一层负责确定通信对象,并确保由足够的资源用于通信,这些当然都是想要通信的应用程序干的事情。
虽然我们收到了传输层传来的数据,可是这些传过来的数据五花八门,有html格式的,有mp4格式的,各种各样。你确定你能看的懂?
因此我们需要指定这些数据的格式规则,收到后才好解读渲染。 例如我们最常见的 Http 数据包中,就会指定该数据包是什么格式的文件了。
HTTP
协议是放在传输的数据里面的
下一层协议都是在上一层协议的数据里面定义的
http协议是基于TCP(上一层协议)协议写的
**http怎么解析的协议??**http协议通过换行符分成一份份的 通过换行符区分不同的数据
比特流(数据)保存在byte数据中 然后一层层的解析 。浏览器和tomcat只需要解析http协议。物理层 数据链路层 网络层 传输层 的协议都由socket解析
HTTPS
下载SSL证书,去nginx.conf中配置
1.0 1.1区别
- http1.0需要使用keep-alive参数来告知服务器端要建立一个长连接,而http1.1默认就是长连接,http是基于tcp/ip协议的,创建一个tcp连接是需要经过三次握手的,有一定的开销,如果每次通讯都要重新建立连接的话,对性能有影响,因此要维持一个长连接,可以用一个长连接来发多个请求
- http1.1支持只发送请求头信息,如果服务器认为客户端有权限请求服务器,则返回101,否则返回401,客户端如果接收了100,才开始把请求体发送到服务器,这样当服务器返回401的时候,客户端就不用再发送请求体了,节约了带宽
- http1.1中新增了24个错误状态响应码,如409表示请求的资源与资源的当前状态发生冲突,410表示服务器上某个资源被永久性的删除
1.1 2.0区别
- http2.0使用了多路复用的技术,做到同一个连接并发处理多个请求,并且并发请求的数量比http1.1大了好几个数量级
- http1.1不支持请求头数据的压缩,http2.0可以对请求头数据进行压缩,传输更快
长短连接
长连接:
但从HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在响应头有加入这行代码:Connection:keep-alive
在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接要客户端和服务端都支持长连接
但是长连接需要保障服务器需要记录每一条长连接的状态,这是会实时消耗CPU和内存的资源的
所以一般长连接——传输速度快、频繁的
短连接:
浏览器和服务器每进行一次HTTP操作,都建立一次连接,都进行三次握手和四次挥手。传输完后快速释放服务器资源
所以一般短连接——传输速度慢一点,不频繁的
如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源,如JavaScript文件、图像文件、CSS文件等;当浏览器每遇到这样一个Web资源,就会建立一个HTTP会话。
一个接口从浏览器发出 到服务器的流程
-
先DNS域名解析(域名 www.baidu.com 变为 ip 地址)。
浏览器搜索自己的DNS缓存(维护一张域名与IP的对应表);若没有,则搜索操作系统的DNS 缓存(维护一张域名与IP的对应表);若没有,则搜索操作系统的hosts文件(维护一张域名与IP 的对应表)。 若都没有,则找 tcp/ip 参数中设置的首选 dns 服务器,即本地 dns 服务器(递归查询),本地 域名服务器查询自己的dns缓存,如果没有,则进行迭代查询。将本地dns服务器将IP返回给操作 系统,同时缓存IP。
-
发起 tcp 的三次握手,建立 tcp 连接。浏览器会以一个随机端口(1024-65535)向服务端的 web 程序 80 端口发起 tcp 的连接。
-
建立 tcp 连接后发起 http 请求。
-
服务器响应 http 请求,客户端得到 html 代码。服务器 web 应用程序收到 http 请求后,就开始处 理请求,处理之后就返回给浏览器 html 文件。
-
浏览器解析 html 代码,并请求 html 中的资源。
-
断开tcp连接
-
浏览器对页面进行渲染,并呈现给用户。
Socket
任何通信的底层都需要到socket
应用层是直接面向用户的,用户直接和应用层打交道,而后边四层则均属于操作系统。在计算机网络通信中应用层是如何和后边四层打交道,或者说我们如何将用户可以识别的字符信息转化成可以被操作系统识别的信息呢?
操作系统为程序员提供了一个交互的接口,也就是Socket。Socket本质上就是操作系统提供给用户做交互用的接口。Socket是应用层与TCP/IP协议族通信的中间软件抽象层,通过socket打包协议,控制协议栈工作,最终通过网卡驱动转化为物理层信息进而进行物理传输。
Socket在传输层中,传输的时候将协议和bit流套起来一起进行传输,另一台设备进行逐步从物理层进行拆分获取信息。
之前利用Socke简单t的代码,两个人在Xshell 运行java文件,进行过一个简单的实时通信,后来做河大论坛的时候,也利用这个建立过一个聊天室
DNS
DNS(域名系统):DNS是由解析器和域名服务器组成的。DNS可以让成千上万的网址和服务器的IP地址一一对应,也就是一台服务器的IP地址对应很多网址
**流程:**当输入一个域名,也就是网址,会先去DNS服务器找到对应的服务器的IP地址,然后设备再根据IP地址找到对应的服务器,从而打开
DNS域名解析过程
1、在浏览器中输入www.qq.com域名,操作系统会先检查自己本地的hosts文件是否有这个网址映射关系,如果有,就先调用这个IP地址映射,完成域名解析。
2、如果hosts里没有这个域名的映射,则查找本地DNS解析器缓存,是否有这个网址映射关系,如果有,直接返回,完成域名解析。
3、如果hosts与本地DNS解析器缓存都没有相应的网址映射关系,首先会找TCP/ip参数中设置的首选DNS服务器,在此我们叫它本地DNS服务器,此服务器收到查询时,如果要查询的域名,包含在本地配置区域资源中,则返回解析结果给客户机,完成域名解析,此解析具有权威性。
4、如果要查询的域名,不由本地DNS服务器区域解析,但该服务器已缓存了此网址映射关系,则调用这个IP地址映射,完成域名解析,此解析不具有权威性。
5、**如果本地DNS服务器本地区域文件与缓存解析都失效,则根据本地DNS服务器的设置(是否设置转发器)进行查询,**如果未用转发模式,本地DNS就把请求发至13台根DNS,根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理,并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后,将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后,如果自己无法解析,它就会找一个管理.com域的下一级DNS服务器地址给本地DNS服务器。当本地DNS服务器收到这个地址后,就会找qq.com域服务器,重复上面的动作,进行查询,直至找到www.qq.com主机。
6、如果用的是转发模式,此DNS服务器就会把请求转发至上一级DNS服务器,由上一级服务器进行解析,上一级服务器如果不能解析,或找根DNS或把转请求转至上上级,以此循环。不管是本地DNS服务器用是是转发,还是根提示,最后都是把结果返回给本地DNS服务器,由此DNS服务器再返回给客户机。
其完整的DNS解析过程有以下几个步骤:
(1)查看浏览器缓存
当用户通过浏览器访问某域名时,浏览器首先会在自己的缓存中查找是否有该域名对应的IP地址(若 曾经访问过该域名且没有清空缓存便存在)。
(2)查看系统缓存
当浏览器缓存中无域名对应IP则会自动检查用户计算机系统Hosts文件DNS缓存是否有该域名对应IP。
(3)查看路由器缓存
当浏览器及系统缓存中均无域名对应IP则进入路由器缓存中检查,以上三步均为客服端的DNS缓存。
(4)查看ISP DNS缓存
当在用户客服端查找不到域名对应IP地址,则将进入ISP DNS缓存中进行查询。比如你用的是电信的网络,则会进入电信的DNS缓存服务器中进行查找。
(5)询问根域名服务器
当以上均未完成,则进入根服务器进行查询。全球仅有13台根域名服务器,1 个主根域名服务器,其余12为辅根域名服务器。根域名收到请求后会查看区域文件记录,若无则将其管辖范围内顶级域名(如.com、 .cn等) 服务器IP 告诉本地DNS服务器。
(6)询问顶级域名服务器
顶级域名服务器收到请求后查看区域文件记录,若无记录则将其管辖范围内权威域名服务器的IP地址告诉本地DNS服务器。
(7)询问权威域名(主域名)服务器
权威域名服务器接受到请求后查询自己的缓存,如果没有则进入下一级域名服务器进行查找,并重复该步骤直至找到正确记录。
(8)保存结果至缓存
本地域名服务器把返回的结果保存到缓存,以备下一次使用,同时将该结果反馈给客户端,
客户端通过这个IP地址即可访问目标Web服务器。至此,DNS递归查询的整个过程结束。
DNS系统承担着将域名解析成IP地址的重要作用,是计算机之间实现访问互联的关键和基
础。因此,DNS解析的安全对于维持网络稳定运行至关重要。企业相关管理者和运营者一
定要做好域名及域名解析的安全防护工作,定期进行数据扫描分析,启用全方位DNS风险
监测,实时关注DNS运行状态,同时做好妥善的应急备份准备,一旦发现问题,出现故
障,第一时间响应解决,才能将DNS故障风险及其带来的损失降至最低点。
断线续传和视频加载
断点续传和视频加载技术都是 文件的切割 将一个文件按照一定的规则人为的分割成多个小文件然后加上序号,然后客户端每次只上传一个小文件(当然我们也可以利用多线程技术每次上传多个小文件),服务器接收到上传过来的小文件后根据一定的规则来组合这些小文件。如果在上传过程中出现网络中断等意外情况,下次再次上传时可以从已经上传的部分继续上传,而不是重新上传。
断点续传 一个文件 分成等大 子文件 传递过程断网了 重新传能续上(子文件也需要编序号,也需要拆分)
视频加载技术 把一个视频拆分成独立的完整的子视频,每一个都能独立播放,发过来一个就能播放,实现了边加载边播放;
网卡
数据传输先以磁介质的形式储存在磁盘中,然后在内存以电容信号存储二进制流,然后内存靠网卡驱动程序通过网卡传递,弱电压信号–>网卡–>强电压信号 。
网卡是通过曼彻斯特编码的电压变化实现的,然后接受到数据后存到内存中,然后比对形状库转成能看的文字等信息
数据的传输统一由网卡中以hashMap的形式存放中所有数据的端口号和数据,每个程序根据自己的端口号去网卡中取数据
端口有六万多个,但是网卡只要一个,意思是网卡中hashMap存储的数据有六万多个
网卡不会主动向程序发送数据,都是程序根据自己的端口号自己通过socket向网卡获取数据,每隔很短一段时间向网卡看一次,程序通过端口号向网卡要数据的过程叫做轮询,时间很短且不受CPU时间切分限制,轮询可能会出现延迟,一般不到1ms
但是在内网之间交互中的轮询的延迟时间会变长,所以出现了socket的升级版NIO框架,NIO框架可以主动把网卡中的数据根据端口号推送到对应的程序中
程序运行一定占据内存 ,虽然数据库的数据存储在磁盘中,但是程序是运行在内存中的,也会占据内存的消耗
送别者 —— 交换机
下面来看一下包是如何通过交换机的。交换机的设计是将网络包原样转发到目的地。交换机工作在 MAC 层,也称为二层网络设备。
交换机的包接收操作
首先,电信号到达网线接口,交换机里的模块进行接收,接下来交换机里的模块将电信号转换为数字信号。
然后通过包末尾的 FCS
校验错误,如果没问题则放到缓冲区。这部分操作基本和计算机的网卡相同,但交换机的工作方式和网卡不同。
计算机的网卡本身具有 MAC 地址,并通过核对收到的包的接收方 MAC 地址判断是不是发给自己的,如果不是发给自己的则丢弃;相对地,交换机的端口不核对接收方 MAC 地址,而是直接接收所有的包并存放到缓冲区中。因此,和网卡不同,交换机的端口不具有 MAC 地址。
将包存入缓冲区后,接下来需要查询一下这个包的接收方 MAC 地址是否已经在 MAC 地址表中有记录了。
交换机的 MAC 地址表主要包含两个信息:
- 一个是设备的 MAC 地址,
- 另一个是该设备连接在交换机的哪个端口上。
交换机根据 MAC 地址表查找 MAC 地址,然后将信号发送到相应的端口。
出境大门 —— 路由器
在具体的操作过程上,路由器和交换机是有区别的。
- 因为路由器是基于 IP 设计的,俗称三层网络设备,路由器的各个端口都具有 MAC 地址和 IP 地址;
- 而交换机是基于以太网设计的,俗称二层网络设备,交换机的端口不具有 IP 地址。
路由器的包接收操作
首先,电信号到达网线接口部分,路由器中的模块会将电信号转成数字信号,然后通过包末尾的 FCS
进行错误校验。
如果没问题则检查 MAC 头部中的接收方 MAC 地址,看看是不是发给自己的包,如果是就放到接收缓冲区中,否则就丢弃这个包。
总的来说,路由器的端口都具有 MAC 地址,只接收与自身地址匹配的包,遇到不匹配的包则直接丢弃。
查询路由表确定输出端口
完成包接收操作之后,路由器就会去掉包开头的 MAC 头部。
MAC 头部的作用就是将包送达路由器,其中的接收方 MAC 地址就是路由器端口的 MAC 地址。因此,当包到达路由器之后,MAC 头部的任务就完成了,于是 MAC 头部就会被丢弃。
接下来,路由器会根据 MAC 头部后方的 IP
头部中的内容进行包的转发操作。
接下来就会进入包的发送操作。
首先,我们需要根据路由表的网关列判断对方的地址。
- 如果网关是一个 IP 地址,则这个IP 地址就是我们要转发到的目标地址,还未抵达终点,还需继续需要路由器转发。
- 如果网关为空,则 IP 头部中的接收方 IP 地址就是要转发到的目标地址,也是就终于找到 IP 包头里的目标地址了,说明已抵达终点。
知道对方的 IP 地址之后,接下来需要通过 ARP
协议根据 IP 地址查询 MAC 地址,并将查询的结果作为接收方 MAC 地址。
路由器也有 ARP 缓存,因此首先会在 ARP 缓存中查询,如果找不到则发送 ARP 查询请求。
接下来是发送方 MAC 地址字段,这里填写输出端口的 MAC 地址。还有一个以太类型字段,填写 0080
(十六进制)表示 IP 协议。
网络包完成后,接下来会将其转换成电信号并通过端口发送出去。这一步的工作过程和计算机也是相同的。
发送出去的网络包会通过交换机到达下一个路由器。由于接收方 MAC 地址就是下一个路由器的地址,所以交换机会根据这一地址将包传输到下一个路由器。
接下来,下一个路由器会将包转发给再下一个路由器,经过层层转发之后,网络包就到达了最终的目的地。
不知你发现了没有,在网络包传输的过程中,源 IP 和目标 IP 始终是不会变的,一直变化的是 MAC 地址,因为需要 MAC 地址在以太网内进行两个设备之间的包传输。
get和post的区别
1、url可见性:
get,参数url可见;
post,url参数不可见
2、数据传输上:
get,通过拼接url进行传递参数;
post,通过body体传输参数
3、缓存性:
get请求是可以缓存的
post请求不可以缓存
4、后退页面的反应
get请求页面后退时,不产生影响
post请求页面后退时,会重新提交请求
5、传输数据的大小
get一般传输数据大小不超过2k-4k(根据浏览器不同,限制不一样,但相差不大)
post请求传输数据的大小根据php.ini 配置文件设定,也可以无限大。
cookie和session的区别
cookie与session区别有:1、对象不同;2、存储数据大小不同;3、生命周期不同;4、存储位置不同;5、数据类型不同;6、安全性不同。其中,定义不同是指cookie是针对每个网站的信息,每个网站只能对应一个,而session是针对每个用户的,只有客户端才能访问。
1、对象不同
cookie:是针对每个网站的信息,每个网站只能对应一个,其他网站无法访问,这个文件保存在客户端,每次您拨打相应网站,浏览器都会查找该网站的 cookies,如果有,则会将该文件发送出去。cookies文件的内容大致上包括了诸如用户名、密码、设置等信息。
session:是针对每个用户的,只有客户端才能访问,程序为该客户添加一个 session。session中主要保存用户的登录信息、操作信息等等。此 session将在用户访问结束后自动消失(如果也是超时)。
2、存储数据大小不同
cookie:一个 cookie存储的数据不超过3K。
session:session存储在服务器上可以任意存储数据。当 session存储数据太多时,服务器可选择进行清理。
3、生命周期不同
cookie:cookie的生命周期当浏览器关闭的时候就消亡了,cookie的生命周期是累计的,从创建时就开始计时,30min后cookie生命周期结束。
session:session的生命周期是间隔的,从创建时开始计时如在30min内没有访问session,那么session生命周期就被销毁。
4、存储位置不同
cookie:cookie数据保存在客户端。
session:session数据保存在服务器端。
5、数据类型不同
两者都是key-value结构,但针对value的类型是有差异的。
cookie:value只能是字符串类型。
session:value是object类型。
6、安全性不同
网站的 cookies,如果有,则会将该文件发送出去。cookies文件的内容大致上包括了诸如用户名、密码、设置等信息。
session:是针对每个用户的,只有客户端才能访问,程序为该客户添加一个 session。session中主要保存用户的登录信息、操作信息等等。此 session将在用户访问结束后自动消失(如果也是超时)。
2、存储数据大小不同
cookie:一个 cookie存储的数据不超过3K。
session:session存储在服务器上可以任意存储数据。当 session存储数据太多时,服务器可选择进行清理。
3、生命周期不同
cookie:cookie的生命周期当浏览器关闭的时候就消亡了,cookie的生命周期是累计的,从创建时就开始计时,30min后cookie生命周期结束。
session:session的生命周期是间隔的,从创建时开始计时如在30min内没有访问session,那么session生命周期就被销毁。
4、存储位置不同
cookie:cookie数据保存在客户端。
session:session数据保存在服务器端。
5、数据类型不同
两者都是key-value结构,但针对value的类型是有差异的。
cookie:value只能是字符串类型。
session:value是object类型。
6、安全性不同
cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,如果主要考虑到安全应当使用session。