文章目录
# 1、OSI模型与TCP/IP模型
层次 | 功能 |
---|---|
应用层 | 为应用程序提供服务并规定应用程序中通信的相关细节,包括文件传输、电子邮件、远程登录等协议。 |
表示层 | 表示层是应用程序和网络之间的翻译官。在表示层,数据需要按照网络所能理解的方案的进行格式化。这种格式化因为使用网络的类型的不同而不同。表示层管理数据的加密和解密,例如银行账户,账户数据发送前加密,接受的时候对账户进行解密。 |
会话层 | 建立通信链接,保持会话过程通信连接的畅通。同步两个节点之间的对话,决定通信是否被中断以及通信中断时决定从何处重新发送。(逻辑上) |
传输层 | 按照网络能处理的最大尺寸将教程的数据包进行强制分割,发送方节点的传输层将数据分割成交小的数据片,同时对每一个数据片安排一序列号,以便数据到达接收方的传输层时能以正确 的顺序重组,该过程称为排序。工作在传输层的两种服务是TCP/IP协议套中的TCP(传输控制协议),另一项传输层服务是IPX/SPX协议集的SPX |
网络层 | 将数据传输到目标地址,目标地址可以是多个网络通过路由器连接而成的某一个地址,因此这一层主要负责寻址和路由选择。 |
数据链路层 | 主要是对物理层传输的比特流包装,检测保证数据传输的可靠性,将物理层接收的数据进行MAC(媒体访问控制)地址的封装和解封装,也可以简单的理解为物理寻址。交换机就处在这一层,最小的传输单位——帧 |
物理层 | 定义物理设备的标准,主要对物理连接方式,电气特性,机械特性等制定统一标准,传输比特流,因此最小的传输单位——位;一切看得到摸得着的无力硬件,例如:网线、光猫、路由器、交换机**(** |
TCP/IP协议分层
层次 | 功能 |
---|---|
应用层 | 决定了向用户提供应用服务时通信的活动,如FTP文件传输协议)和DNS。 |
传输层 | 对上层应用层,提供处于网络连接中国的两台计算机之间的数据传输,如 TCP和UDP. |
网络层 | c处理在网络上流动的数据包,数据包是网络传输的最小数据单位,该层规定了通过怎样的路径到达对方计算机, |
链路层 | 用来处理连接网络的硬件部分 |
应用层:为特定应用程序提供数据传输服务,例如
HTTP
,DNS
等协议,数据单位为报文传输层:为进程提供通用数据传输服务。由于应用层协议众多,定义通用的传输协议就可以支持不断增多的应用层协议。运输层包括两种协议:
传输控制协议TCP
(提供面向连接,可靠的传输服务,数据单位为报文段;);用户数据包协议(UDP)
:提供无连接,尽最大努力的数据传输服务,数据单位为用户数据段。TCP主要提供完整性服务,UDP主要提供及时性服务
2、网络响应码分类?
HTTP 响应状态代码指示特定 HTTP 请求是否已成功完成。
响应分为五类:
信息响应
100-199
成功响应
200-299
重定向
300-399
客户端错误
400-499
服务端错误
500-599
常用的一些状态码:
200 ok
: 表示客户端发来的请求在服务器端被正常处理了。302 Found
: 临时重定向,该状态表示请求的资源已被分配了新的URI400 Bad Request
: 该状态码表示请求报文中存在语法错误,当错误发生时,需修改请求的内容后再次发送请求。401 Unauthorized:
发送的请求需要通过HTTP认证的认证信息404 Not Found:
服务器上没有请求的资源500 Internal Server Error:
服务器端在执行请求时发生了错误
3、Http方法
- GET
- post
- PUT
- HEAD
- OPTIONS
- TRACE
- DELETE
- CONNECT
请求方法 作用 GET(获取资源) 用来获取请求访问已被URI识别的资源,指定的资源经服务器端解析返回响应内容。默认 POST(传输实体主体) 用来传输实体的主体,与GET方法类似,但一般不用GET方法,不容易造成信息泄露 PUT(传输文件) 就像FTP协议的文件上传一样,要求在报文的主体内容中包含文件内容,然后保存到请求的URI指定的位置。(存在安全问题,不常用) HEAD(获得报文首部) 和GET方法一样,只是不返回报文主体部分,用于确认URI的有效性及资源更新的日期时间。 DELETE(删除文件) 用来删除文件,是与PUT相反的方法,DELETE方法按请求URI删除指定的资源(一般也不实用) OPTIONS(询问支持的方法) 查询针对请求URI指定的资源支持的方法。 TRACE(追踪路径) 让WEB服务器端将之前的请求通信返回给客户端的方法。
Http幂等性
HTTP 幂等方法
,是指无论调用多少次都不会有不同结果的 HTTP 方法。不管你调用一次,还是调用一百次,一千次,结果都是相同
的。
HTTP DELETE
方法用于删除资源,会将资源删除。
幂等的方法
HTTP GET 方法
,用于获取资源,不管调用多少次接口,结果都不会改变,所以是幂等
的。
HTTP PATCH 方法
,因为它直接把实体部分的数据替换到服务器的资源,我们多次调用它,只会产生一次影响,但是有相同结果的 HTTP 方法,所以满足幂等性。
HTTP PUT方法
,是幂等的,因此表示更新资源更贴切
非幂等的方法
HTTP POST
方法是一个非幂等方法,因为调用多次,都将产生新的资源。
HTTP PATCH
方法是非幂等的。
6、forward和redirect的区别?
forward
是转发;redirect
是重定向地址栏显示:
forward url
不会发生改变;redirect url
会发生改变数据共享:
forward
可以共享request里的数据,redirect
不能共享效率:
forward
比redirect
效率高
7、简述tcp和udp的区别?
tcp
和udp
是OSI
模型中的运输层的协议。
tcp
提供可靠的通信传输,而udp
则常用于让广播和细节控制交给应用的通信传输两者的区别大致如下:
tcp
面向连接,udp
面向非连接即发送数据前不需要建立连接tcp
提供可靠的服务(数据传输),udp
无法保证;tap
面向字节流,udp
面向报文tcp
传输数据满,udp
传输数据块
- 用户数据包协议UDP(User Datageam protocol): 是面向无连接的,尽最大了能完成交付,没有堵塞控制,面向报文(对于应用程序传下来的报文不合并也不拆分,只是添加UDP首部,支持一对一,一对多,多对一和多对多的交互信息)
- 传输控制协议TCP(Transmission Control Protocol)是面向连接的,提供可靠交互,有流量控制,拥塞控制,提供全双工通信,面向字节流(把应用层传下来的报文看成字节流,把字节流组织称大小不等的数据块),每一条TCP连接都只能是点对点(一堆一)。(其中TCP的为序号包括什么?
TCP UDP 面向连接 无连接 传输速度慢 传输速度快 保证数据有序到达 不保证数据有序到达 保证数据正确性 可能丢包 TCP报文段 UDP用户数据报 系统资源要求多(需要内核维护发送/接受缓冲区) 要求少(不需要内核维护缓冲区, 直接将数据报发送到网络上, 或直接交付给进程) 适用于对效率要求相对低,但对准确性要求相对高的场景下,或者是有一种连接概念的场景(如HTTP服务) 适用于对效率要求相对高,对准确性要求相对低的场景(如视频点播) 所以如果我们的发送消息,浏览网页之类的场景,因为要确保用户信息不丢失,要使用TCP协议。如果是在视频或看直播,那可以使用UDP协议,因为即使几个画面丢失,对用户来说影响也不大
11、使用TCP的协议
FTP(文件传输协议);Telnet(远程登录协议),SMTP(简单邮件传输协议),HTTP协议
12、Session与Coockie的区别
相同:都是用来跟踪浏览器用户身份的会话方式。
不同:
(1)session是保存在服务器端,跟踪用户状态,可保存在集群、数据库、文件等。Cookie是保存在客户端的,是session的一种实现方式。
(2)Cookie不是很安全,别人可以分析存放在本地的cookie并进行cookie欺骗,如果考虑到安全应该使用session.
(3)Session会在一定时间内保存在服务器上,当访问增多,会占用服务器的性能,如果主要考虑到减轻服务器性能方面,应当使用cookie
(4)登陆信息等重要信息存放为session。其他信息如果需要保留,可以放在cookie中
服务器端如何能识别特定的用户。
原理:当第一次创建session时,服务器端会在http协议中告诉客户端,在cookie上保存sessionId,每次http请求时,客户端都会发送相应cookie信息给服务器端。
14、IP头部协议?
IP协议是TCP/IP协议族的动力,它为上层协议提供无状态
,无连接
,不可靠的服务
4位版本号
:IP协议(IPV4)版本号为44位首部长度
:标值头部有多少个4字节,即最大长度为15x4个字节8位服务类型
:包含一个4位优先权字段:最小延时,最大吞吐量,最高可靠性和最小费用16位总长度
:表示整个IP数据报的长度,即最大表示65535,但由于MTU的限制,一般无法达到这个值16位标志
:唯一的标志数据报,系统采用加1的方式边发送边赋值3位标志
:(保留,DF禁止分片,MF更多分片):所以这个标志是为了分片存在的,DF设置时禁止分片所以如果数据报太大则发送失败。MF设置时,如果产生分片,除了最后一个分片,其他次片设置为113为分片便宜
:分片相对原始IP数据报开始出的便宜8位生存时间(TTL)
:数据报到大目的地之间允许经过的路由跳跳数,跳一下减一,为0时丢弃8位头协议
:用来区分上层协议(ICMP为1,TCP为6,UDP为17)16位头部校验和
:仅以CRC算法校验数据报头部在传输过程中是否损坏32位源端口IP地址和目的端地址
可变长
:记录路由,告诉途径的所有路由把IP天津来,。 时间戳:告诉每个路由器将数据报被转发的时间传进来。 松散路由选择:指定一个路由器IP地址列表。
TCP协议详解>>>>
TCP协议详解>>>>
TCP协议详解>>>>
TCP协议详解>>>>
13、TCPt头部格式
16位端口号
:表示该段报文来自哪里(源端口)以及要传给上从协议或应用程序(目的端口)
32位序号
😗*表示一次tcp通信过程中(从建立连接到断开)过程中某一次传输方向上的字节流中的每个字节的编号。假定主机A和B进行TCP通信,A传送给B一个tcp保文段中,序号值被系统初始化为某一个随机值ISN
,那么在该传输方向上(从A到B),后序的所有tcp报文段中的序号值都被设定为ISN
加上该报文daunt所携带数据的第一个字节在整个字节流中的偏移。例如某个TCP
报文段传送的数据是字节流中的第1025~2048
字节,那么该报文段的序号值就是ISN+1025
**为什么序号要被初始化伪随机值
32位确认号
:用作对另一发方送的tcp报文段的响应。其值是收到对方的tcp
报文段的序号值+1。假定主机A和B进行TCP通信,那么A发出tcp报文段不但带有自己的序号,也包含了对B发送来的tcp
扒皮文段的确认号,反之也一样
4位头部长度
:表示tcp头部有多少个32bit字,因为4位最大值就是15,所以最多有15个32bit,也就是60个字节是最大的tcp头部长度6位标志为:
URG
:紧急指针是否有效ack
表示确认号是否有效,携带·ack`标志的报文段也称为确认报文段psh
提示接收端应用程序应给立即从tcp接受缓冲区读取数据,为后序接受的数据让出空间
RST
表示要求对方重建连接,带RST
表值的报文段也叫作复位报文段SYN
表示建立一个连接,携带SYN
的tcp报文段为同步报文段FIN
:表示告知对方本端要关闭连接了
16位窗口大小
:是TCP流量控制的一个手段,这里说的窗口是指接收通知窗口,它告诉对方本端的tcp接受缓冲区还能容纳多少字节的数据,这样对方就能控制发送数据
16位校验和1
:由发送端填充,接受端对tcp
报文段执行CRC
算法以校验TCP
报文段在传输过程中是否损坏,注意这个校验不仅包括tcp头部,也包括数据部分。这也是tcp
可靠传输的一个重要保障、
16位紧急指针
:是一个证的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一个字节的序号。因此这个字段是紧急指针相对当前序号的偏移量,发送紧急数据会用到这个
TCP头部选项
:最后一项是可变长的可选信息,最多包含40字节的数据
15、TCP要三次握手,四次挥手?
三次握手
最初两端的TCP进程都处于CLOSED关闭状态,A主动打开连接,而B被动打开连接。(A、B关闭状态CLOSED——B收听状态LISTEN——A同步已发送状态SYN-SENT——B同步收到状态SYN-RCVD——A、B连接已建立状态ESTABLISHED)
为什么要三次握手
四次挥手
假设Client端发起中断连接请求,也就是发送FIN报文。Server端接到FIN报文后,意思是说"我Client端没有数据要发给你了",但是如果你还有数据没有发送完成,则不必急着关闭Socket,可以继续发送数据。所以你先发送ACK,“告诉Client端,你的请求我收到了,但是我还没准备好,请继续你等我的消息”。这个时候Client端就进入FIN_WAIT状态,继续等待Server端的FIN报文。当Server端确定数据已发送完成,则向Client端发送FIN报文,“告诉Client端,好了,我这边数据发完了,准备好关闭连接了”。Client端收到FIN报文后,"就知道可以关闭连接了,但是他还是不相信网络,怕Server端不知道要关闭,所以发送ACK后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传。“,Server端收到ACK后,“就知道可以断开连接了”。Client端等待了2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,我Client端也可以关闭连接了。Ok,TCP连接就这样关闭了!
起初A和B处于ESTABLISHED状态——A发出连接释放报文段并处于FIN-WAIT-1状态——B发出确认报文段且进入CLOSE-WAIT状态——A收到确认后,进入FIN-WAIT-2状态,等待B的连接释放报文段——B没有要向A发出的数据,B发出连接释放报文段且进入LAST-ACK状态——A发出确认报文段且进入TIME-WAIT状态——B收到确认报文段后进入CLOSED状态——A经过等待计时器时间2MSL后,进入CLOSED状态。
为什么要四次挥手
答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
Time_waiting(几乎必问)
为什么A在TIME-WAIT状态必须等待2MSL的时间?
MSL最长报文段寿命Maximum Segment Lifetime,MSL=2
答: 两个理由:1**)保证A发送的最后一个ACK报文段能够到达B。2)防止“已失效的连接请求报文段”出现在本连接中。
- 1)这个ACK报文段有可能丢失,使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认,B超时重传FIN+ACK报文段,而A能在2MSL时间内收到这个重传的FIN+ACK报文段,接着A重传一次确认,重新启动2MSL计时器,最后A和B都进入到CLOSED状态,若A在TIME-WAIT状态不等待一段时间,而是发送完ACK报文段后立即释放连接,则无法收到B重传的FIN+ACK报文段,所以不会再发送一次确认报文段,则B无法正常进入到CLOSED状态。
- 2)A在发送完最后一个ACK报文段后,再经过2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失,使下一个新的连接中不会出现这种旧的连接请求报文段。
16、TCP协议是如何保证传输可靠性?
TCP协议传输的特点主要就是面向字节流、传输可靠、面向连接。我们就重点讨论一下TCP协议如何确保传输的可靠性的。
TCP协议保证数据传输可靠性的方式主要有:
校验和
序列号
确认应答
超时重传
连接管理
流量控制
拥塞控制
检验和
计算方式
:在数据传输的过程中,将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃,补在后面,最后取反,得到校验和。
发送方
:在发送数据之前计算检验和,并进行校验和的填充。
接收方
:收到数据后,对数据以同样的方式进行计算,求出校验和,与发送方的进行比对。注意:如果接收方比对校验和与发送方不一致,那么数据一定传输有误。但是如果接收方比对校验和与发送方一致,数据不一定传输成功。
确认应答与序列号
序列号
:TCP传输时将每个字节的数据都进行了编号,这就是序列号。
确认应答
:TCP传输的过程中,每次接收方收到数据后,都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号,告诉发送方,接收到了哪些数据,下一次的数据从哪里发。
超时重传
在进行TCP传输时,由于确认应答与序列号机制,也就是说发送方发送一部分数据后,都会等待接收方发送的ACK报文,并解析ACK报文,判断数据是否传输成功。如果发送方发送完数据后,迟迟没有等到接收方的ACK报文,这该怎么办呢?而没有收到ACK报文的原因可能是什么呢?
首先,发送方没有介绍到响应的ACK报文原因可能有两点:
- 数据在传输过程中由于网络原因等直接全体丢包,接收方根本没有接收到。
- 接收方接收到了响应的数据,但是发送的ACK报文响应却由于网络原因丢包了。
TCP在解决这个问题的时候引入了一个新的机制,叫做超时重传机制。简单理解就是发送方在发送完数据后等待一个时间,时间到达没有接收到ACK报文,那么对刚才发送的数据进行重新发送。如果是刚才第一个原因,接收方收到二次重发的数据后,便进行ACK应答。如果是第二个原因,接收方发现接收的数据已存在(判断存在的根据就是序列号,所以上面说序列号还有去除重复数据的作用),那么直接丢弃,仍旧发送ACK应答。
连接管理
连接管理就是三次握手与四次挥手的过程
重排
重排: TCP承载于IP数据报来传输,而IP数据报的到达可能会失序,因此TCP报文段的到达也可能会失序。TCP将对收到的数据进行重新排序。IP数据报会发生重复,TCP的接收端会丢弃重复的数据。
分割
分割: 应用数据被分割成TCP认为最适合发送的数据块,称为TCP报文段传递给IP层。
流量控制
TCP根据接收端对数据的处理能力,绝定发送端的发送速度,这个机制就是流量控制。TCP协议的报头信息中,有一个16位字段的窗口大小,发送方根据ACK报文里面的窗口大小的值进而改变自己的发送速度
接收端在接收到数据后,对其进行处理。如果发送端的发送速度太快,导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据,那么接下来发送的数据都会丢包,继而导致丢包的一系列连锁反应,超时重传呀什么的。而TCP根据接收端对数据的处理能力,决定发送端的发送速度,这个机制就是流量控制
在TCP协议的报头信息当中,有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道,**窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。**这个数字越大,证明接收端接收缓冲区的剩余空间越大,网络的吞吐量越大。接收端会在确认应答发送ACK报文时,将自己的即时窗口大小填入,并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0,那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段,让接收端把窗口大小告诉发送端。
参考资料滑动窗口
TCP 采用大小可变的滑动窗口进行流量控制(窗口大小的单位是字节), 在 TCP 报文段首部的窗口字段写入的数值就是当前给对方设置的发送窗口数值的上限。
发送窗口在连接建立时由双方商定。但在通信的过程中,接收端可根据自己的资源情况,随时动态地调整对方的发送窗口上限值(可增大或减小)。
拥塞控制
慢开始
TCP传输的过程中,发送端开始发送数据的时候,如果刚开始就发送大量的数据,那么就可能造成一些问题。网络可能在开始的时候就很拥堵,如果给网络中在扔出大量数据,那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包,就对大量的超时重传,严重影响传输。
\1. 发送端的主机在确定发送报文段的速率时,既要根据接收端的接收能力,又要从全局考虑不要使网络发生拥塞。因此,每一个 TCP 连接需要有以下两个状态变量:
接收窗口 rwnd (receiver window)
: 这是接收端根据其目前的接收缓存大小所许诺的最新的窗口值,是来自接收端的流量控制。接收端将此窗口值放在 TCP 报文的首部中的窗口字段,传送给发送端。
拥塞窗口 cwnd (congestion window):
是发送端根据自己估计的网络拥塞程度而设置的窗口值,是来自发送端的流量控制。发送端的发送窗口的上限值应当取为接收端窗口 rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个,即应按以下公式确定:
发送窗口的上限值 = Min(rwnd, cwnd)
使用慢开始算法后,每经过一个传输轮次(即往返时延RTT),拥塞窗口cwnd就会加倍,即cwnd的大小呈指数形式增长(可以看出”慢开始”并不”慢”)。这样慢开始一直把拥塞窗口cwnd增大到一个规定的慢开始门限ssthresh(阈值),然后改用拥塞避免算法。
拥塞窗口的增长是指数级别的。慢启动的机制只是说明在开始的时候发送的少,发送的慢,但是增长的速度是非常快的。为了控制拥塞窗口的增长,不能使拥塞窗口单纯的加倍,设置一个拥塞窗口的阈值,当拥塞窗口大小超过阈值时,不能再按照指数来增长,而是线性的增长。在慢启动开始的时候,慢启动的阈值等于窗口的最大值,一旦造成网络拥塞,发生超时重传时,慢启动的阈值会为原来的一半(这里的原来指的是发生网络拥塞时拥塞窗口的大小),同时拥塞窗口重置为 1。
小结:
在慢开始和拥塞避免算法中使用了“乘法减小”和“加法增大”方法。“乘法减小”是指不论在慢开始阶段还是拥塞避免阶段,只要出现一次超时(即很可能出现了网络拥塞),就把慢开始门限值ssthresh设置为当前的拥塞窗口值的一半。当网络频繁出现拥塞时,ssthresh值就下降得很快,以大大减少注入到网络中的分组数。而“加法增大”是指执行拥塞避免算法后,在收到对所有报文段的确认后(即经过一个RTT),就把拥塞窗口cwnd增加一个MSS大小,使拥塞窗口缓慢增大,以防止网络过早出现拥塞。
快重传和快恢复
快重传和快恢复算法是对慢开始和拥塞避免算法的改进。
1.快重传
当发送方连续收到
三个重复的ACK报文
时,直接重传对方尚未收到的报文段,而不必等待那个报文段设置的重传计时器超时。2.快恢复
快恢复算法原理:当发送端收到连续三个冗余ACK(即重复确认)时,就执行“乘法减小”算法,把慢开始门限ssthresh减半。与慢开始(慢开始算法将拥塞窗口cwnd设置为1)不同之处是它把cwnd的值设置为慢开始门限ssthresh减半后的数值,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大。
由于跳过了cwnd从1起始的慢开始过程(因为既然现在能够收到三个重复ACK确认, 就说明拥塞程序并不是很大),所以被称为快恢复。
快恢复算法的实现过程如下图所示,作为对比,虚线为慢开始的处理过程。
发送方发送窗口的实际大小由流量控制和拥塞控制共同决定。因此,当同时出现了接收端窗口(rwnd)和拥塞窗口(cwnd)时,发送方实际的发送窗口大小是由rwnd和cwnd中较小的那一个确定的
17、DNS域名解析
DNS占用
53
号端口,同时使用TCP
和UDP
协议DNS区域传输的时候使用
TCP
协议:
- 辅域名服务器会定时(一般三个小时)向主域名服务器进行查询以便了解数据是否有变动,如有变动,会执行一次区域传送,进行数据同步。区域传送使用
TCP
而不是UDP
,因为数据同步传送的数据量比一个请求应答的数句量要多的多。- TCP是一种可靠连接,保证了数据传输额准确性
域名解析时使用
UDP
协议客户端向
DNS
服务器查询域名,一般返回的内容都不超过512
字节,用UDP传输即可。不用经过三次握手,这样DNS
服务器负载更低,响应更快。理论上说,客户端也可以指定向DNS
服务器查询时使用TCP
,但事实上,很多DNS
服务器进行配置的时候,仅支持UDP
查询包
23、输入网址之后发生了什么?
1、回车键按下后,浏览器会对输入的地址数据进行解析:
1.1、检查输入的URL是http协议,请求资源是对应主机名网站主页。
1.2、然后检查浏览器的严格安全传输列表( HSTS列表 ),如果网站在列表中,则浏览器直接使用https协议进行传输,否则直接使用http协议传输,或者先使用http协议向网站服务器发送一个请求,服务器返回浏览器只能以https协议进行,则接下来仍然只以https协议来进行传输。
1.3、然后检查输入地址中是否有非ASCII码的unicode字符,如果有的话进行字符转换。
1.4、当协议或主机名不合法时,浏览器会将地址栏中输入的内容传递给默认的搜索引擎。2、然后进行DNS递归查询(
域名解析
2.1浏览器缓存
– 浏览器会缓存DNS记录一段时间。 有趣的是,操作系统没有告诉浏览器储存DNS记录的时间,这样不同浏览器会储存个自固定的一个时间(2分钟到30分钟不等)。
2.2、系统缓存
– 如果在浏览器缓存里没有找到需要的记录,浏览器会做一个系统调用(windows里是gethostbyname)。这样便可获得系统缓存中的记录。
2.3、路由器缓存
– 接着,前面的查询请求发向路由器,它一般会有自己的DNS缓存。
ISP DNS 缓存 – 接下来要check的就是ISP缓存DNS的服务器。在这一般都能找到相应的缓存记录。
2.4、递归搜索
– 你的ISP的DNS服务器从跟域名服务器开始进行递归搜索,从.com顶级域名服务器到Facebook的域名服务器。一般DNS服务器的缓存中会有.com域名服务器中的域名,所以到顶级服务器的匹配过程不是那么必要了。3、使用套接字进行数据访问
3.1、浏览器获得目标IP地址,以及URL中给出的端口号(http 协议默认端口号是 80, https 默认端口号是 443),调用系统库函数socket
,请求一个TCP流套接字。
3.2、该请求首先被交给传输层,封装成TCP segment,然后被送往网络层,添加目标服务器IP地址以及本机的IP地址,封装成TCP packet,再接下来会进入链路层,在封包中加入frame头部,包含本机网卡的MAC地址和网关MAC地址等,形成最终的TCP封包。
3.3、TCP封包完成之后,会通过以太网等网络进行传输到目标地址。4、建立TCP连接
建立TCP
连接会进行三次握手的过程,然后进行发送HTTP请求过程和接收过程。
4.1、进行三次握手,首先向服务器发送一个syn报文,其中SYN=1
,seq number=1022(随机);
4.2、服务器接收到syn报文,根据syn=1判断客户端请求建立连接,并返回一个SYN
报文,为第一次握手,其中ack number=1023(客户端seq number+1),seq number=2032(随机),syn=1,ack=1;
4.3、客户端根据服务器的SYN
报文,确认其ack number是否与上一次发送的seq number+1相等,且ACK
=1,确认正确,则回应一个ack报文,为第二次握手,即ack number=2033(服务器seq number+1),ACK
=1,
4.4、服务器根据接收到的ACK
报文,确认ack number是否与上一次发送的seq number+1相等,并且ACK
=1,确认正确,则建立连接,进入Established状态,为第三次握手。
4.5、建立TCP连接后,会使用HTTP协议发送HTTP的GET请求,服务器处理请求返回资源数据。5、浏览器处理数据
5.1、再接收到所请求的资源之后,浏览器会对接收到的html、css、js等数据根据标准格式进行解析。
5.2、然后会通过构建和遍历DOM节点树,进行各个节点的渲染计算,最后进行GPU的渲染布局和绘制步骤等。
18、HTTP报文结构和状态码
请求格式
**个HTTP请求报文由
请求行(request line)
、请求头部(header)
、空行
和请求数据
4个部分组成,下图给出了请求报文的一般格式。 **
- 请求行
请求行由
请求方法字段
、URL字段
和HTTP协议版本字段3
个字段组成,它们用空格
分隔。 HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
- 请求头部
请求头部
由关键字/值对
组成,每行一对
,关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息,典型的请求头有:
User-Agent
:产生请求的浏览器类型。
Accept:
客户端可识别的内容类型列表。
Host:
请求的主机名,允许多个域名同处一个IP地址,即虚拟主机。
- 请求数据
请求数据不在GET方法中使用,而是在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length。
响应格式
HTTP响应也由三个部分组成,分别是:状态行、消息报头、响应正文。
HTTP/1.1 200 OK Date: Sat, 31 Dec 2005 23:59:59 GMT Content-Type: text/html;charset=ISO-8859-1 Content-Length: 122 <html> <head> <title>Wrox Homepage</title> </head> <body> <!-- body goes here --> </body> </html>
HTTP 响应状态代码指示特定 HTTP 请求是否已成功完成。
响应分为五类:
信息响应
100-199
成功响应
200-299
重定向
300-399
客户端错误
400-499
服务端错误
500-599
常用的一些状态码:
200 ok
: 表示客户端发来的请求在服务器端被正常处理了。302 Found
: 临时重定向,该状态表示请求的资源已被分配了新的URI400 Bad Request
: 该状态码表示请求报文中存在语法错误,当错误发生时,需修改请求的内容后再次发送请求。401 Unauthorized:
发送的请求需要通过HTTP认证的认证信息404 Not Found:
服务器上没有请求的资源500 Internal Server Error:
服务器端在执行请求时发生了错误
HTTP /1.1新特性
- 支持流水线
- 支持同时打开多个TCP连接
- 新增状态码100:目前为止都很正常,客户端可以继续发送请求或者忽略这个响应
- 支持分块传输编码:可以把数据分隔成多块,让浏览器逐步显示页面
- 新增缓存处理指令max-age:有效期来指定
Cookie
的持久性问题
get/POST的区别
传输数据格式
传输数据大小
传输数据安全性
1
.GET提交
,请求的数据会附在URL之后(就是把数据放置在HTTP协议头<request-line>中),以?分割URL和传输数据,多个参数用&连接;例如:login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字,原样发送,如果是空格,转换为+,如果是中文/其他字符,则直接把字符串用BASE64加密,得出如: %E4%BD%A0%E5%A5%BD,其中%XX中的XX为该符号以16进制表示的ASCII。
POST
提交:把提交的数据放置在是HTTP包的包体<request-body>中。上文示例中红色字体标明的就是实际的传输数据因此,GET提交的数据会在地址栏中显示出来,而POST提交,地址栏不会改变
2.
传输数据的大小:
首先声明,HTTP协议没有对传输的数据大小进行限制,HTTP协议规范也没有对URL长度进行限制。 而在实际开发中存在的限制主要有:
GET:特定浏览器和服务器对URL长度有限制,例如IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器,如Netscape、FireFox等,理论上没有长度限制,其限制取决于操作系统的支因此对于GET提交时,传输数据就会受到URL长度的限制。 POST:由于不是通过URL传值,理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制,Apache、IIS6都有各自的配置。
3、
安全性
**POST的安全性要比GET的安全性高。**注意:这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改,而这里安全的含义是真正的Security的含义,比如:通过GET提交数据,用户名和密码将明文出现在URL上,因为(1)登录页面有可能被浏览器缓存, (2)其他人查看浏览器的历史纪录,那么别人就可以拿到你的账号和密码
缓存问题
Web 缓存大致可以分为:
数据库缓存
、服务器端缓存(代理服务器缓存、CDN 缓存)
、浏览器缓存
。浏览器缓存也包含很多内容: HTTP 缓存、indexDB、cookie、localstorage 等等。这里我们只讨论 HTTP 缓存相关内容。
在具体了解 HTTP 缓存之前先来明确几个术语:
缓存命中率
:从缓存中得到数据的请求数与所有请求数的比率。理想状态是越高越好。过期内容
:超过设置的有效时间,被标记为“陈旧”的内容。通常过期内容不能用于回复客户端的请求,必须重新向源服务器请求新的内容或者验证缓存的内容是否仍然准备。验证
:验证缓存中的过期内容是否仍然有效,验证通过的话刷新过期时间。失效
:失效就是把内容从缓存中移除。当内容发生改变时就必须移除失效的内容。HTTP头信息控制缓存
大致分为两种:
强缓存
和协商缓存
。强缓存如果命中缓存不需要和服务器端发生交互,而协商缓存不管是否命中都要和服务器端发生交互,强制缓存的优先级高于协商缓存。
匹配流程(已有缓存的情况下):
强缓存
可以理解为无须验证的缓存策略
。对强缓存来说,响应头中有两个字段Expires/Cache-Control
来表明规则。协商缓存
缓存的资源到期了,并不意味着资源内容发生了改变,如果和服务器上的资源没有差异,实际上没有必要再次请求。
客户端和服务器端通过某种验证机制验证当前请求资源是否可以使用缓存。
**浏览器第一次请求数据之后会将数据和响应头部的缓存标识存储起来。再次请求时会带上存储的头部字段,服务器端验证是否可用。**如果返回 304 Not Modified,代表资源没有发生改变可以使用缓存的数据,获取新的过期时间。反之返回 200 就相当于重新请求了一遍资源并替换旧资源。 Last-modified/If-Modified-Since
Last-modified: 服务器端资源的最后修改时间,响应头部会带上这个标识。第一次请求之后,浏览器记录这个时间,再次请求时,请求头部带上 If-Modified-Since 即为之前记录下的时间。服务器端收到带 If-Modified-Since 的请求后会去和资源的最后修改时间对比。若修改过就返回最新资源,状态码 200,若没有修改过则返回 304。
Etag/If-None-Match
由服务器端上生成的一段 hash 字符串,第一次请求时响应头带上 ETag: abcd,之后的请求中带上 If-None-Match: abcd,服务器检查 ETag,返回 304 或 200。
19、GET与POST的比较:作用、参数、安全性、幂等性、可缓存性
作用
:get用于获取资源,POST用于传输实体主体
参数
:GET与POST的请求都能使用额外的参数,但是GET的参数是以查询字符串出现在URL中,而POST的参数存储在实体主体中
修改性
:HTTP方法不会改变服务器状态,GET方法是安全的,而POST却不是,因为POST的目的是传送这个实体的主体内容,这个内容肯梦是用户上传的表单数据,上传之后,服务器可能吧这个数据存储到数据库中,因此状态也就发生了改变
幂等性
:GET是幂等性的,连续调用多次,客户端接受到的结果都是一样的,POST不是幂等的,如果调用多次,就会增加多行记录;所以查询数据用GET,新增操作用PIST
可缓存
:get可缓存(响应状态码和Cache-Control保证是可缓存的),post不可缓存
底层
:对于GET方式的请求,浏览器会把header 和data一起发送出去,服务器响应200(返回数据);而对POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200
20、Cookie作用、安全性问题和Session的比较?
Cookie是服务器发送到用户浏览器并保存到本地的一小块数据,它会在浏览器之后向通一个服务器再次发起请求时被携带上,用于告知服务器这两个请求是否来自同一个浏览器。可用左会话状态管理(如用户登录状态,购物车,游戏分数或其他需要记录的信息)、个性化设置、浏览区行为跟踪。可能被浏览器禁用,
Session存储在服务器端,存储在服务器端的信息更加安全。
使用Session维护用户登录状态的过如下(需要COOKIE作为传输机制)
用户进行登录时,用户提交包含用户名和密码的表单,放入HTTP请求报文中;服务器返回的响应报文的
Set-cookie
首部字段包括了这个SessioiD
,客户端收到响应报文后将Cookie存入浏览器中;客户端之后对同一个服务器请求时会包含该Cookie值,服务器收到之后提取出SessionId
区别
- Cookie只能存储
ASCII
妈字符串,而Session
则可以存取任何类型的数据,因此在考虑数据卷复杂性的时候首选Session
Cookie
存储在浏览器中,容易被恶意查看。如果非要将一些隐私数据存放在Cookie中,可以将COOKIE值进行加密,然后再服务器中进行解密- 对于大型网站,如果用户所有的信息都存储在
Session
中,那么开销是非常大的,因此不建议所有的用户信息都存储在session
中小绝
存储位置
都是会话技术
Cookie
存储在客户端,相当于临时文件
Session
存储在服务器端安全性
Cookie
有安全隐患,通过拦截或者本地文件得到你的Cookie进行攻击。
Session
相对比较安全大小限制
Cookie
有大小限制,单个不超过4k
,浏览器中Cookie个数也有限制
Session
没有大小限制生命周期
Cookie
的生命周期可以设置,默认是一次会话的时间
Session
生命周期是可以间隔的,关闭服务器会造成会话结束
21、短连接与长连接、流水线?
当浏览器访问一个包含多张图片的
HTML
页面时,除了请求访问HTML
页面资源,还会请求图片资源。如果每进行一次HTTP通信就要新建一个TCP
连接,那么开销会很大。长连接只需要建立一次TCP
连接就能进行多次HTTP
通信在HTTP/1.1之前默认是短连接的,如果需要使用长连接,则使用`Connewction-Keep Alive.
从Http/1.1开始默认是长连接的,如果要断开连接,需要由客户端或服务器端提出断开,使用`Connection:close·
流水线
默认情况下,
http
请求是按照顺序发出的,下一个请求只有在当前请求收到响应之后才会发出,由于受到网络延迟和带宽的限制,在下一个请求被发送到服务器之前,可能需要等待很长的时间流水线是在同一条长连接上发出连续的请求,而不用等待响应返回,这样可以避免连接延迟
22、http的安全性问题
使用明文进行通信,内容可能会被窃听
不验证通信方的身份,同新方的身份有可能遭遇伪装
无法证明报文的完整性,报文有可能遭遇篡改
通过使用
SSL
,HTTPS
具有加密(防窃听)、认证(防伪装)和完整性保护(防篡改)。
HTTPS
采用混合的加密机制,使用非对称秘钥加密用于传输对称秘钥来保证传输过程的安全性,之后使用对称秘钥来进行通信过程的效率HTTS加密过程
- 客户使用https的URL访问WEB服务器,要求与Web服务器建立SSL连接
- Web服务器收到客户端请求后,会将网站的证书信息(证书中包含公钥)传送一份给客户端
- 客户端的浏览器与Web服务器开始协商SSL连接的安全等级,也就是信息加密等级
- 客户端浏览器根据双方同意的安全等级,建立会话秘钥,然后利用网站的公钥将会话秘钥加密,并传送给网站
- WEB服务器利用自己的私钥解密出会话秘钥
- WEB服务器利用会话秘钥加密与客户端之间的通信
缺点:
因为需要进行加密解密等过程,因此速度比较慢;
需要支付证书授权额高额费用
22、HTTP与FTP的异同点?
同
- 都是应用层协议;
- 都运行在TCP上,即都使用TCP(而不是UDP)作为其支撑的运输层协议
异
- HTTP是超文本传输协议,是面向网页的;FTP是文件传输协议,是面向文件的
- FTP服务器必须在整个会话期间保留用户的状态信息,而HTTP是无状态的
- FTP使用两个并行的TCP连接来传输文件,一个是控制连接,一个是数据连接。FTP的控制连接是持久连接,数据连接是非持久连接;而HTTP既可以是非持久连接,也可以是持久连接
24、Http与Https的区别
Http与Https的关系
超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息,HTTP协议以明文方式发送内容,不提供任何方式的数据加密,如果攻击者截取了Web浏览器和网站服务器之间的传输报文,就可以直接读懂其中的信息,因此,HTTP协议不适合传输一些敏感信息,比如:信用卡号、密码等支付信息。
为了解决Http协议的这一缺陷,需要使用另一种协议:安全套接字层超文本传输协议
hTTPS
,为了数据传输的安全性,Https在Http的基础上加入了SSL协议,SSL依靠证书来验证服务器的身份,并为浏览器和服务器之间的通信加密
Http和Https的基本概念
HTTP:是互联网上应用最为广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议,它可以使浏览器更加高效,使网络传输减少。
HTTPS:是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP下加入SSL层,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。
HTTPS协议的主要作用可以分为两种:
一种是建立一个信息安全通道,来保证数据传输的安全
;另一种就是确认网站的真实性
。
Http与Https有什么区别
HTTP协议传输的数据都是未加密的,也就是明文的
,因此使用HTTP协议传输隐私信息非常不安全,为了保证这些隐私数据能加密传输,于是网景公司设计了SSL(Secure Sockets Layer)协议用于对HTTP协议传输的数据进行加密,从而就诞生了HTTPS。简单来说,HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全。
HTTPS和HTTP的区别主要如下:
1、 https协议需要到ca申请证书,一般免费证书较少,因而需要一定费用。
2、http是超文本传输协议,信息是明文传输,https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443
4、http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全
Https的工作原理
我们都知道HTTPS能够加密信息,以免敏感信息被第三方获取,所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。
客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤,如图所示。
(1)客户使用https的URL访问Web服务器,要求与Web服务器建立SSL连接。
(2)Web服务器收到客户端请求后,会将网站的证书信息(证书中包含公钥)传送一份给客户端。
(3)客户端的浏览器与Web服务器开始协商SSL连接的安全等级,也就是信息加密的等级。
(4)客户端的浏览器根据双方同意的安全等级,建立会话密钥,然后利用网站的公钥将会话密钥加密,并传送给网站。
(5)Web服务器利用自己的私钥解密出会话密钥。
(6)Web服务器利用会话密钥加密与客户端之间的通信。
Https的优点
尽管HTTPS并非绝对安全,掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击,但HTTPS仍是现行架构下最安全的解决方案,主要有以下几个好处:
(1)使用HTTPS协议可认证用户和服务器,确保数据发送到正确的客户机和服务器;
(2)HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全,可防止数据在传输过程中不被窃取、改变,确保数据的完整性。
(3)HTTPS是现行架构下最安全的解决方案,虽然不是绝对安全,但它大幅增加了中间人攻击的成本。
(4)谷歌曾在2014年8月份调整搜索引擎算法,并称“比起同等HTTP网站,采用HTTPS加密的网站在搜索结果中的排名将会更高”。
Https的缺点
虽然说HTTPS有很大的优势,但其相对来说,还是存在不足之处的:
(1)HTTPS协议握手阶段比较费时,会使页面的加载时间延长近50%,增加10%到20%的耗电;
(2)HTTPS连接缓存不如HTTP高效,会增加数据开销和功耗,甚至已有的安全措施也会因此而受到影响;
(3)SSL证书需要钱,功能越强大的证书费用越高,个人网站、小网站没有必要一般不会用。
(4)SSL证书通常需要绑定IP,不能在同一IP上绑定多个域名,IPv4资源不可能支撑这个消耗。
(5)HTTPS协议的加密范围也比较有限,在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的,SSL证书的信用链体系并不安全,特别是在某些国家可以控制CA根证书的情况下,中间人攻击一样可行。
http切换到Https
如果需要将网站从http切换到https到底该如何实现呢?
这里需要将页面中所有的链接,例如js,css,图片等等链接都由http改为https。例如:http://www.baidu.com改为https://www.baidu.com
BTW,这里虽然将http切换为了https,还是建议保留http。所以我们在切换的时候可以做http和https的兼容,具体实现方式是,去掉页面链接中的http头部,这样可以自动匹配http头和https头。例如:将http://www.baidu.com改为//www.baidu.com。然后当用户从http的入口进入访问页面时,页面就是http,如果用户是从https的入口进入访问页面,页面即使https的。
25、用户反映你开发的网站访问很慢可能会是什么原因
原因
-
可能的原因一:
服务器出口带宽不够用
。这是一个很常见的瓶颈。一方面,可能是本身购买的服务器出口带宽就很小(企业购买带宽相当昂贵),一旦用户访问量上来了,并发量大了,自然均分给用户的出口带宽就更小了,所以某些用户的访问速度就会下降了很多。另一个,就是跨运营商网络导致带宽缩减,例如很多公司的网站(服务器)是放在电信的网络上的,而如果用户这边对接的是长城或者说联通的宽带,运营商之间网络传输在对接时是会有限制的,这就可能导致带宽的缩减。 -
可能原因二:
服务器负载过大忙不过来
,比如说CPU和内存消耗完了,这个容易理解,不展开。 -
可能原因三:
网站的开发代码没写好
,例如mysql语句没有进行优化,导致数据库的读写相当耗费时间。 -
可能原因四:
数据库的瓶颈
,也是很常见的一个瓶颈,这点跟上面第三个原因可以一起来说。当我们的数据库变得愈发庞大,比如好多G好多T这么大,那对于数据库的读写就会变得相当缓慢了,索引优化固然能提升一些效率,但数据库已经如此庞大的话,如果每次查询都对这么大的数据库进行全局查询,自然会很慢。这个学过数据库的话也是挺容易理解的。
方法和工具检测
- 某个用户反馈网站访问变慢,怎么去定位问题。首先你自己也打开下网站,看是否会出现用户反映的问题,如果你这边访问没问题,那就可能是用户那边的问题了,这块就是要先确定是用户那一方的问题还是自身比如说服务器或者网站的问题。
- 发现确实是自己服务器或者网站的问题,那么可以利用浏览器的调试功能(一般浏览器都会有),调试网络看看各种数据加载的速度,哪一项消耗了多少时间都可以看到,是哪块数据耗时过多,是图片加载太慢,还是某些数据加载老半天都查不出来。
- 然后针对服务器的负载情况,可以去查看下服务器硬件(网络带宽、CPU、内存)的消耗状况。带宽方面查看流量监控看是不是已经到了峰值,带宽不够用了,如果是公司自己买服务器搭的网站服务器的话,需要自己搭建监控环境;如果用的是阿里云腾讯云这些的,那这些平台那边会提供各方面的监控比如CPU、带宽等等,在后台就可以看到了。
- 果发现硬件资源消耗都不高,都比较充裕,那要去看看是不是程序的问题了。这个可以通过查日志来找,比如PHP日志、Apache日志、mysql日志等等的错误日志,特别如mysql有个慢查询的日志功能,可以看到是不是某条mysql语句特别慢,如果某条语句花的时间太长,那这条语句很有可能有问题。
- 至于说到的数据库太庞大,这个直接看就看得到了,比如一个表的文件大小变得特别大了。
针对上面的这些问题,有哪些解决和优化的办法呢
- 出口带宽的问题,这个很简单,加带宽,有钱就多买带宽,很简单。
- )mysql语句优化,开发人员职责。
- 数据库太庞大,为了读写速度,进行“拆表”、“拆库”,就是把数据表或者数据库进行拆分。
- 上面的拆库拆表都是针对数据库实在太庞大才会这样做,一般在此之前会有其他优化方法,比如mysql的主从复制,一台主服务器专门用于写,然后其他从服务器用来读,写完之后会同步更新到其他读的服务器中。例如阿里的双十一活动,都不知道用了多少万台服务器一起在扛着。
- 还有这几年用得比较多的非关系型数据库,它使用了缓存机制,它把数据缓存到了内存,用户访问数据直接从内存读取,读取速度就比在磁盘中读取快了很多,还有它的一个key-value读取机制,这个听师兄说之后没听懂。
- CDN(content-delivery-network:内容分发网络),鸡蛋放在多个篮子里,把数据放在离用户更近的位置(例如网站的一些静态文件比如图片或者js脚本),用户访问时判断IP来源是广州,那就通过智能DNS解析到广州的服务器上,直接从广州的篮子里去获取数据,速度就快了。这里有个静态数据和动态数据的概念,例如图片和一些js文件一般是不变的,那就可以把它们的映像分布到全国各地,加快速度,而一些需要在网站后台动态产生的一些数据,则需要去到网站所在的服务器去产生并得到。这个涉及到两种数据的显示的问题,这就交由浏览器处理了。同时异步加载的技术例如前端的Ajax技术,异步请求数据,可以使这些动态数据延迟加载,这块自己不怎么了解,可能表述不好。前端开发的人员应该更懂一些。