共计 18423 个字符,预计需要花费 47 分钟才能阅读完成。
网络分层构造
计算机网络体系大抵分为三种,OSI 七层模型、TCP/IP 四层模型和五层模型。个别面试的时候考查比拟多的是五层模型。最全面的 Java 面试网站
五层模型:应用层、传输层、网络层、数据链路层、物理层。
- 应用层:为应用程序提供交互服务。在互联网中的应用层协定很多,如域名零碎 DNS、HTTP 协定、SMTP 协定等。
- 传输层:负责向两台主机过程之间的通信提供数据传输服务。传输层的协定次要有传输控制协议 TCP 和用户数据协定 UDP。
- 网络层:抉择适合的路由和替换结点,确保数据及时传送。次要包含 IP 协定。
- 数据链路层:在两个相邻节点之间传送数据时,数据链路层将网络层交下来的 IP 数据报组装成帧,在两个相邻节点间的链路上传送帧。
- 物理层:实现相邻节点间比特流的通明传输,尽可能屏蔽传输介质和物理设施的差别。
本文曾经收录到 Github 仓库,该仓库蕴含 计算机根底、Java 根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享 等外围知识点,欢送 star~
Github 地址
如果拜访不了 Github,能够拜访 gitee 地址。
gitee 地址
ISO 七层模型 是国际标准化组织(International Organization for Standardization)制订的一个用于计算机或通信零碎间互联的规范体系。
- 应用层:网络服务与最终用户的一个接口,常见的协定有:HTTP FTP SMTP SNMP DNS.
- 表示层:数据的示意、平安、压缩。,确保一个零碎的应用层所发送的信息能够被另一个零碎的应用层读取。
- 会话层:建设、治理、终止会话, 对应主机过程,指本地主机与近程主机正在进行的会话.
- 传输层:定义传输数据的协定端口号,以及流控和过错校验, 协定有TCP UDP.
- 网络层:进行逻辑地址寻址,实现不同网络之间的门路抉择, 协定有ICMP IGMP IP 等.
- 数据链路层:在物理层提供比特流服务的根底上,建设相邻结点之间的数据链路。
- 物理层:建设、保护、断开物理连贯。
TCP/IP 四层模型
- 应用层:对应于 OSI 参考模型的(应用层、表示层、会话层)。
- 传输层: 对应 OSI 的传输层,为应用层实体提供端到端的通信性能,保障了数据包的程序传送及数据的完整性。
- 网际层:对应于 OSI 参考模型的网络层,次要解决主机到主机的通信问题。
- 网络接口层:与 OSI 参考模型的数据链路层、物理层对应。
三次握手
假如发送端为客户端,接收端为服务端。开始时客户端和服务端的状态都是CLOSED
。
- 第一次握手:客户端向服务端发动建设连贯申请,客户端会随机生成一个起始序列号 x,客户端向服务端发送的字段中蕴含标记位
SYN=1
,序列号seq=x
。第一次握手前客户端的状态为CLOSE
,第一次握手后客户端的状态为SYN-SENT
。此时服务端的状态为LISTEN
。 - 第二次握手:服务端在收到客户端发来的报文后,会随机生成一个服务端的起始序列号 y,而后给客户端回复一段报文,其中包含标记位
SYN=1
,ACK=1
,序列号seq=y
,确认号ack=x+1
。第二次握手前服务端的状态为LISTEN
,第二次握手后服务端的状态为SYN-RCVD
,此时客户端的状态为SYN-SENT
。(其中SYN=1
示意要和客户端建设一个连贯,ACK=1
示意确认序号无效) - 第三次握手:客户端收到服务端发来的报文后,会再向服务端发送报文,其中蕴含标记位
ACK=1
,序列号seq=x+1
,确认号ack=y+1
。第三次握手前客户端的状态为SYN-SENT
,第三次握手后客户端和服务端的状态都为ESTABLISHED
。 此时连贯建设实现。
两次握手能够吗?
之所以须要第三次握手,次要为了 避免已生效的连贯申请报文段 忽然又传输到了服务端,导致产生问题。
- 比方客户端 A 收回连贯申请,可能因为网络阻塞起因,A 没有收到确认报文,于是 A 再重传一次连贯申请。
- 而后连贯胜利,期待数据传输结束后,就开释了连贯。
- 而后 A 收回的第一个连贯申请等到连贯开释当前的某个工夫才达到服务端 B,此时 B 误认为 A 又收回一次新的连贯申请,于是就向 A 收回确认报文段。
- 如果不采纳三次握手,只有 B 收回确认,就建设新的连贯了,此时 A 不会响应 B 的确认且不发送数据,则 B 始终期待 A 发送数据,浪费资源。
四次挥手
- A 的利用过程先向其 TCP 收回连贯开释报文段(
FIN=1,seq=u
),并进行再发送数据,被动敞开 TCP 连贯,进入FIN-WAIT-1
(终止期待 1)状态,期待 B 的确认。 - B 收到连贯开释报文段后即收回确认报文段(
ACK=1,ack=u+1,seq=v
),B 进入CLOSE-WAIT
(敞开期待)状态,此时的 TCP 处于半敞开状态,A 到 B 的连贯开释。 - A 收到 B 的确认后,进入
FIN-WAIT-2
(终止期待 2)状态,期待 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 才进入CLOSED
状态。B 收到 A 收回的确认报文段后敞开连贯,若没收到 A 收回的确认报文段,B 就会重传连贯开释报文段。
第四次挥手为什么要期待 2MSL?
- 保障 A 发送的最初一个 ACK 报文段可能达到 B 。这个
ACK
报文段有可能失落,B 收不到这个确认报文,就会超时重传连贯开释报文段,而后 A 能够在2MSL
工夫内收到这个重传的连贯开释报文段,接着 A 重传一次确认,重新启动 2MSL 计时器,最初 A 和 B 都进入到CLOSED
状态,若 A 在TIME-WAIT
状态不期待一段时间,而是发送完 ACK 报文段后立刻开释连贯,则无奈收到 B 重传的连贯开释报文段,所以不会再发送一次确认报文段,B 就无奈失常进入到CLOSED
状态。 - 避免已生效的连贯申请报文段呈现在本连贯中 。A 在发送完最初一个
ACK
报文段后,再通过 2MSL,就能够使这个连贯所产生的所有报文段都从网络中隐没,使下一个新的连贯中不会呈现旧的连贯申请报文段。
最初给大家分享一个 Github 仓库,下面有大彬整顿的 300 多本经典的计算机书籍 PDF,包含 C 语言、C++、Java、Python、前端、数据库、操作系统、计算机网络、数据结构和算法、机器学习、编程人生 等,能够 star 一下,下次找书间接在下面搜寻,仓库继续更新中~
Github 地址
为什么是四次挥手?
因为当 Server 端收到 Client 端的 SYN
连贯申请报文后,能够间接发送 SYN+ACK
报文。然而在敞开连贯时,当 Server 端收到 Client 端收回的连贯开释报文时,很可能并不会立刻敞开 SOCKET,所以 Server 端先回复一个 ACK
报文,通知 Client 端我收到你的连贯开释报文了。只有等到 Server 端所有的报文都发送完了,这时 Server 端能力发送连贯开释报文,之后两边才会真正的断开连接。故须要四次挥手。
说说 TCP 报文首部有哪些字段,其作用又别离是什么?
- 16 位端口号:源端口号,主机该报文段是来自哪里;指标端口号,要传给哪个下层协定或应用程序
- 32 位序号:一次 TCP 通信(从 TCP 连贯建设到断开)过程中某一个传输方向上的字节流的每个字节的编号。
- 32 位确认号:用作对另一方发送的 tcp 报文段的响应。其值是收到的 TCP 报文段的序号值加 1。
- 4 位头部长度:示意 tcp 头部有多少个 32bit 字(4 字节)。因为 4 位最大能标识 15,所以 TCP 头部最长是 60 字节。
- 6 位标记位:URG(紧急指针是否无效),ACk(示意确认号是否无效),PSH(缓冲区尚未填满),RST(示意要求对方从新建设连贯),SYN(建设连贯音讯标记接),FIN(示意告知对方本端要敞开连贯了)
- 16 位窗口大小:是 TCP 流量管制的一个伎俩。这里说的窗口,指的是接管通告窗口。它通知对方本端的 TCP 接收缓冲区还能包容多少字节的数据,这样对方就能够管制发送数据的速度。
- 16 位校验和:由发送端填充,接收端对 TCP 报文段执行 CRC 算法以测验 TCP 报文段在传输过程中是否损坏。留神,这个校验不仅包含 TCP 头部,也包含数据局部。这也是 TCP 牢靠传输的一个重要保障。
- 16 位紧急指针:一个正的偏移量。它和序号字段的值相加示意最初一个紧急数据的下一字节的序号。因而,确切地说,这个字段是紧急指针绝对以后序号的偏移,无妨称之为紧急偏移。TCP 的紧急指针是发送端向接收端发送紧急数据的办法。
TCP 有哪些特点?
- TCP 是 面向连贯 的运输层协定。
- 点对点,每一条 TCP 连贯只能有两个端点。
- TCP 提供 牢靠交付 的服务。
- TCP 提供 全双工通信。
- 面向字节流。
TCP 和 UDP 的区别?
- TCP面向连贯;UDP 是无连贯的,即发送数据之前不须要建设连贯。
- TCP 提供 牢靠的服务;UDP 不保障牢靠交付。
- TCP面向字节流,把数据看成一连串无构造的字节流;UDP 是面向报文的。
- TCP 有 拥塞管制;UDP 没有拥塞管制,因而网络呈现拥塞不会使源主机的发送速率升高(对实时利用很有用,如实时视频会议等)。
- 每一条 TCP 连贯只能是 点到点 的;UDP 反对一对一、一对多、多对一和多对多的通信形式。
- TCP 首部开销 20 字节;UDP 的首部开销小,只有 8 个字节。
TCP 和 UDP 别离对应的常见应用层协定有哪些?
基于 TCP 的应用层协定有:HTTP、FTP、SMTP、TELNET、SSH
- HTTP:HyperText Transfer Protocol(超文本传输协定),默认端口 80
- FTP: File Transfer Protocol (文件传输协定), 默认端口(20 用于传输数据,21 用于传输管制信息)
- SMTP: Simple Mail Transfer Protocol (简略邮件传输协定) , 默认端口 25
- TELNET: Teletype over the Network (网络电传), 默认端口 23
- SSH:Secure Shell(平安外壳协定),默认端口 22
基于 UDP 的应用层协定:DNS、TFTP、SNMP
- DNS : Domain Name Service (域名服务), 默认端口 53
- TFTP: Trivial File Transfer Protocol (简略文件传输协定),默认端口 69
- SNMP:Simple Network Management Protocol(简略网络管理协定),通过 UDP 端口 161 接管,只有 Trap 信息采纳 UDP 端口 162。
TCP 的粘包和拆包
TCP 是面向流,没有界线的一串数据。TCP 底层并不理解下层业务数据的具体含意,它会依据 TCP 缓冲区的理论状况进行包的划分,所以在业务上认为,一 个残缺的包可能会被 TCP 拆分成多个包进行发送 , 也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的 TCP 粘包和拆包问题。
为什么会产生粘包和拆包呢?
- 要发送的数据小于 TCP 发送缓冲区的大小,TCP 将屡次写入缓冲区的数据一次发送进来,将会产生粘包;
- 接收数据端的应用层没有及时读取接收缓冲区中的数据,将产生粘包;
- 要发送的数据大于 TCP 发送缓冲区残余空间大小,将会产生拆包;
- 待发送数据大于 MSS(最大报文长度),TCP 在传输前将进行拆包。即 TCP 报文长度 -TCP 头部长度 >MSS。
解决方案:
- 发送端将每个数据包封装为固定长度
- 在数据尾部减少特殊字符进行宰割
- 将数据分为两局部,一部分是头部,一部分是内容体;其中头部构造大小固定,且有一个字段申明内容体的大小。
说说 TCP 是如何确保可靠性的呢?
- 首先,TCP 的连贯是基于 三次握手 ,而断开则是基于 四次挥手。确保连贯和断开的可靠性。
- 其次,TCP 的可靠性,还体现在 有状态;TCP 会记录哪些数据发送了,哪些数据被接管了,哪些没有被承受,并且保障数据包按序达到,保障数据传输不出差错。
- 再次,TCP 的可靠性,还体现在 可管制 。它有数据包校验、ACK 应答、 超时重传(发送方)、失序数据重传(接管方)、抛弃反复数据、流量管制(滑动窗口)和拥塞管制等机制。
说下 TCP 的滑动窗口机制
TCP 利用滑动窗口实现流量管制。流量管制是为了管制发送方发送速率,保障接管方来得及接管。TCP 会话的单方都各自保护一个发送窗口和一个接管窗口。接管窗口大小取决于利用、零碎、硬件的限度。发送窗口则取决于对端通告的接管窗口。接管方发送的确认报文中的 window 字段能够用来管制发送方窗口大小,从而影响发送方的发送速率。将接管方的确认报文 window 字段设置为 0,则发送方不能发送数据。
TCP 头蕴含 window 字段,16bit 位,它代表的是窗口的字节容量,最大为 65535。这个字段是接收端通知发送端本人还有多少缓冲区能够接收数据。于是发送端就能够依据这个接收端的解决能力来发送数据,而不会导致接收端解决不过去。接管窗口的大小是约等于发送窗口的大小。
具体讲一下拥塞管制?
避免过多的数据注入到网络中。几种拥塞管制办法:慢开始 (slow-start)、拥塞防止(congestion avoidance)、快重传(fast retransmit) 和快复原(fast recovery)。
慢开始
把拥塞窗口 cwnd 设置为一个最大报文段 MSS 的数值。而在每收到一个对新的报文段的确认后,把拥塞窗口减少至少一个 MSS 的数值。每通过一个传输轮次,拥塞窗口 cwnd 就加倍。为了避免拥塞窗口 cwnd 增长过大引起网络拥塞,还须要设置一个慢开始门限 ssthresh 状态变量。
当 cwnd < ssthresh 时,应用慢开始算法。
当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞防止算法。
当 cwnd = ssthresh 时,既可应用慢开始算法,也可应用拥塞管制防止算法。
拥塞防止
让拥塞窗口 cwnd 迟缓地增大,每通过一个往返工夫 RTT 就把发送方的拥塞窗口 cwnd 加 1,而不是加倍。这样拥塞窗口 cwnd 按线性法则迟缓增长。
无论在慢开始阶段还是在拥塞防止阶段,只有发送方判断网络呈现拥塞(其依据就是没有收到确认),就要把慢开始门限 ssthresh 设置为呈现拥塞时的发送 方窗口值的一半(但不能小于 2)。而后把拥塞窗口 cwnd 从新设置为 1,执行慢开始算法。这样做的目标就是要迅速缩小主机发送到网络中的分组数,使得产生 拥塞的路由器有足够工夫把队列中积压的分组处理完毕。
快重传
有时个别报文段会在网络中失落,但实际上网络并未产生拥塞。如果发送方迟迟收不到确认,就会产生超时,就会误认为网络产生了拥塞。这就导致发送方谬误地启动慢开始,把拥塞窗口 cwnd 又设置为 1,因此升高了传输效率。
快重传算法能够防止这个问题。快重传算法首先要求接管方每收到一个失序的报文段后就立刻收回反复确认,使发送方及早晓得有报文段没有达到对方。
发送方只有一连收到三个反复确认就该当立刻重传对方尚未收到的报文段,而不用持续期待重传计时器到期。因为发送方尽早重传未被确认的报文段,因而采纳快重传后能够使整个网络吞吐量进步约 20%。
快复原
当发送方间断收到三个反复确认,就会把慢开始门限 ssthresh 减半,接着把 cwnd 值设置为慢开始门限 ssthresh 减半后的数值,而后开始执行拥塞防止算法,使拥塞窗口迟缓地线性增大。
在采纳快复原算法时,慢开始算法只是在 TCP 连贯建设时和网络呈现超时时才应用。采纳这样的拥塞管制办法使得 TCP 的性能有显著的改良。
HTTP 协定的特点?
- HTTP 容许传输 任意类型 的数据。传输的类型由 Content-Type 加以标记。
- 无状态。对于客户端每次发送的申请,服务器都认为是一个新的申请,上一次会话和下一次会话之间没有分割。
- 反对 客户端 / 服务器模式。
HTTP 报文格式
HTTP 申请由 申请行、申请头部、空行和申请体 四个局部组成。
- 申请行 :包含申请办法,拜访的资源 URL,应用的 HTTP 版本。
GET
和POST
是最常见的 HTTP 办法,除此以外还包含DELETE、HEAD、OPTIONS、PUT、TRACE
。 - 申请头:格局为“属性名: 属性值”,服务端依据申请头获取客户端的信息,次要有
cookie、host、connection、accept-language、accept-encoding、user-agent
。 - 申请体:用户的申请数据如用户名,明码等。
申请报文示例:
POST /xxx HTTP/1.1 申请行
Accept:image/gif.image/jpeg, 申请头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=dabin 申请体
HTTP 响应也由四个局部组成,别离是:状态行、响应头、空行和响应体。
- 状态行:协定版本,状态码及状态形容。
- 响应头:响应头字段次要有
connection、content-type、content-encoding、content-length、set-cookie、Last-Modified,、Cache-Control、Expires
。 - 响应体:服务器返回给客户端的内容。
响应报文示例:
HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112
<html>
<body> 响应体 </body>
</html>
HTTP 状态码有哪些?
HTTP 状态码是服务器端返回给客户端的响应状态码,依据状态码咱们就能晓得服务器端想要给客户端表白的具体含意,比方 200 就示意申请拜访胜利,500 就示意服务器端程序出错等。HTTP 状态码可分为 5 大类:
- 1XX:音讯状态码。
- 2XX:胜利状态码。
- 3XX:重定向状态码。
- 4XX:客户端谬误状态码。
- 5XX:服务端谬误状态码。
这 5 大类中又蕴含了很多具体的状态码。
1XX 为 音讯状态码,其中:
- 100:Continue 持续。客户端应持续其申请。
- 101:Switching Protocols 切换协定。服务器依据客户端的申请切换协定。只能切换到更高级的协定,例如,切换到 HTTP 的新版本协定。
2XX 为 胜利状态码,其中:
- 200:OK 申请胜利。个别用于 GET 与 POST 申请。
- 201:Created 已创立。胜利申请并创立了新的资源。
- 202:Accepted 已承受。曾经承受申请,但未解决实现。
- 203:Non-Authoritative Information 非受权信息。申请胜利。但返回的 meta 信息不在原始的服务器,而是一个正本。
- 204:No Content 无内容。服务器胜利解决,但未返回内容。在未更新网页的状况下,可确保浏览器持续显示以后文档。
- 205:Reset Content 重置内容。服务器解决胜利,用户终端(例如:浏览器)应重置文档视图。可通过此返回码革除浏览器的表单域。
- 206:Partial Content 局部内容。服务器胜利解决了局部 GET 申请。
3XX 为 重定向状态码,其中:
- 300:Multiple Choices 多种抉择。申请的资源可包含多个地位,相应可返回一个资源特色与地址的列表用于用户终端(例如:浏览器)抉择。
- 301:Moved Permanently 永恒挪动。申请的资源已被永恒的挪动到新 URI,返回信息会包含新的 URI,浏览器会主动定向到新 URI。今后任何新的申请都应应用新的 URI 代替。
- 302:Found 长期挪动,与 301 相似。但资源只是长期被挪动。客户端应持续应用原有 URI。
- 303:See Other 查看其它地址。与 301 相似。应用 GET 和 POST 申请查看。
- 304:Not Modified 未修改。所申请的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存拜访过的资源,通过提供一个头信息指出客户端心愿只返回在指定日期之后批改的资源。
- 305:Use Proxy 应用代理。所申请的资源必须通过代理拜访。
- 306:Unused 曾经被废除的 HTTP 状态码。
- 307:Temporary Redirect 长期重定向。与 302 相似。应用 GET 申请重定向。
4XX 为客户端 谬误状态码,其中:
- 400:Bad Request 客户端申请的语法错误,服务器无奈了解。
- 401:Unauthorized 申请要求用户的身份认证。
- 402:Payment Required 保留,未来应用。
- 403:Forbidden 服务器了解申请客户端的申请,然而拒绝执行此申请。
- 404:Not Found 服务器无奈依据客户端的申请找到资源(网页)。通过此代码,网站设计人员可设置 ” 您所申请的资源无奈找到 ” 的共性页面。
- 405:Method Not Allowed 客户端申请中的办法被禁止。
- 406:Not Acceptable 服务器无奈依据客户端申请的内容个性实现申请。
- 407:Proxy Authentication Required 申请要求代理的身份认证,与 401 相似,但请求者该当应用代理进行受权。
- 408:Request Time-out 服务器期待客户端发送的申请工夫过长,超时。
- 409:Conflict 服务器实现客户端的 PUT 申请时可能返回此代码,服务器解决申请时产生了抵触。
- 410:Gone 客户端申请的资源曾经不存在。410 不同于 404,如果资源以前有当初被永恒删除了可应用 410 代码,网站设计人员可通过 301 代码指定资源的新地位。
- 411:Length Required 服务器无奈解决客户端发送的不带 Content-Length 的申请信息。
- 412:Precondition Failed 客户端申请信息的先决条件谬误。
- 413:Request Entity Too Large 因为申请的实体过大,服务器无奈解决,因而拒绝请求。为避免客户端的间断申请,服务器可能会敞开连贯。如果只是服务器临时无奈解决,则会蕴含一个 Retry-After 的响应信息。
- 414:Request-URI Too Large 申请的 URI 过长(URI 通常为网址),服务器无奈解决。
- 415:Unsupported Media Type 服务器无奈解决申请附带的媒体格式。
- 416:Requested range not satisfiable 客户端申请的范畴有效。
- 417:Expectation Failed 服务器无奈满足 Expect 的申请头信息。
5XX 为 服务端谬误状态码,其中:
- 500:Internal Server Error 服务器外部谬误,无奈实现申请。
- 501:Not Implemented 服务器不反对申请的性能,无奈实现申请。
- 502:Bad Gateway 作为网关或者代理工作的服务器尝试执行申请时,从近程服务器接管到了一个有效的响应。
- 503:Service Unavailable 因为超载或系统维护,服务器临时的无奈解决客户端的申请。延时的长度可蕴含在服务器的 Retry-After 头信息中。
- 504:Gateway Time-out 充当网关或代理的服务器,未及时从远端服务器获取申请。
- 505:HTTP Version not supported 服务器不反对申请的 HTTP 协定的版本,无奈实现解决。
总结一下:
HTTP 状态码分为 5 大类:1XX:示意音讯状态码;2XX:示意胜利状态码;3XX:示意重定向状态码;4XX:示意客户端谬误状态码;5XX:示意服务端谬误状态码。其中常见的具体状态码有:200:申请胜利;301:永恒重定向;302:长期重定向;404:无奈找到此页面;405:申请的办法类型不反对;500:服务器外部出错。
HTTP 协定包含哪些申请?
HTTP 协定中共定义了八种办法来示意对 Request-URI 指定的资源的不同操作形式,具体如下:
- GET:向特定的资源发出请求。
- POST:向指定资源提交数据进行解决申请(例如提交表单或者上传文件)。数据被蕴含在申请体中。POST 申请可能会导致新的资源的创立和 / 或已有资源的批改。
- OPTIONS:返回服务器针对特定资源所反对的 HTTP 申请办法。也能够利用向 Web 服务器发送 ’*’ 的申请来测试服务器的功能性。
- HEAD:向服务器索要与 GET 申请相一致的响应,只不过响应体将不会被返回。这一办法能够在不用传输整个响应内容的状况下,就能够获取蕴含在响应音讯头中的元信息。
- PUT:向指定资源地位上传其最新内容。
- DELETE:申请服务器删除 Request-URI 所标识的资源。
- TRACE:回显服务器收到的申请,次要用于测试或诊断。
- CONNECT:HTTP/1.1 协定中预留给可能将连贯改为管道形式的代理服务器。
HTTP 状态码 301 和 302 的区别?
- 301:(永久性转移)申请的网页已被永恒挪动到新地位。服务器返回此响应时,会主动将请求者转到新地位。
- 302:(暂时性转移)服务器目前正从不同地位的网页响应申请,但请求者应持续应用原有地位来进行当前的申请。此代码与响应 GET 和 HEAD 申请的 301 代码相似,会主动将请求者转到不同的地位。
举个形象的例子:当一个网站或者网页 24—48 小时内长期挪动到一个新的地位,这时候就要进行 302 跳转,打个比方说,我有一套房子,然而最近走亲戚去亲戚家住了,过两天我还回来的。而应用 301 跳转的场景就是之前的网站因为某种原因须要移除掉,而后要到新的地址拜访,是永久性的,就比方你的那套房子其实是租的,当初租期到了,你又在另一个中央找到了房子,之前租的房子不住了。
POST 和 GET 的区别?
- GET 和 POST 最实质的区别是标准上的区别,在标准中,定义 GET 申请是用来获取资源的,也就是进行查问操作的,而 POST 申请是用来传输实体对象的,因而会应用 POST 来进行增加、批改和删除等操作。
- GET 申请参数通过 URL 传递,POST 的参数放在申请体中。
- GET 申请能够间接进行回退和刷新,不会对用户和程序产生任何影响;而 POST 申请如果间接回滚和刷新将会把数据再次提交。
- GET 产生一个 TCP 数据包;POST 产生两个 TCP 数据包。对于 GET 形式的申请,浏览器会把申请头和申请体一并发送进来;而对于 POST,浏览器先发送申请头,服务器响应 100 continue,浏览器再发送申请体。
- GET 申请个别会被缓存,比方常见的 CSS、JS、HTML 申请等都会被缓存;而 POST 申请默认是不进行缓存的。
- GET 申请参数会被残缺保留在浏览器历史记录里,而 POST 中的参数不会被保留。
URI 和 URL 的区别
- URI,全称是 Uniform Resource Identifier),中文翻译是对立资源标志符,次要作用是惟一标识一个资源。
- URL,全称是 Uniform Resource Location),中文翻译是对立资源定位符,次要作用是提供资源的门路。打个经典比喻吧,URI 像是身份证,能够惟一标识一个人,而 URL 更像一个住址,能够通过 URL 找到这个人。
如何了解 HTTP 协定是无状态的
当浏览器第一次发送申请给服务器时,服务器响应了;如果同个浏览器发动第二次申请给服务器时,它还是会响应,然而呢,服务器不晓得你就是方才的那个浏览器。简言之,服务器不会去记住你是谁,所以是无状态协定。
HTTP 长连贯和短连贯?
HTTP 短连贯:浏览器和服务器每进行一次 HTTP 操作,就建设一次连贯,工作完结就中断连贯。HTTP1.0 默认应用的是短连贯。
HTTP 长连贯:指的是 复用 TCP 连贯。多个 HTTP 申请能够复用同一个 TCP 连贯,这就节俭了 TCP 连贯建设和断开的耗费。
HTTP/1.1 起,默认应用长连贯。要应用长连贯,客户端和服务器的 HTTP 首部的 Connection 都要设置为 keep-alive,能力反对长连贯。
HTTP 如何实现长连贯?
HTTP 分为长连贯和短连贯,实质上说的是 TCP 的长短连贯。TCP 连贯是一个双向的通道,它是能够放弃一段时间不敞开的,因而 TCP 连贯才具备真正的长连贯和短连贯这一说法哈。
TCP 长连贯能够复用一个 TCP 连贯,来发动屡次的 HTTP 申请,这样就能够缩小资源耗费,比方一次申请 HTML,如果是短连贯的话,可能还须要申请后续的 JS/CSS。
如何设置长连贯?
通过在头部(申请和响应头)设置 Connection 字段指定为keep-alive
,HTTP/1.0 协定反对,然而是默认敞开的,从 HTTP/1.1 当前,连贯默认都是长连贯。
HTTP 长连贯在什么时候会超时?
HTTP 个别会有 httpd 守护过程,外面能够设置keep-alive timeout,当 tcp 连贯闲置超过这个工夫就会敞开,也能够在 HTTP 的 header 外面设置超时工夫。
TCP 的 keep-alive 蕴含三个参数,反对在零碎内核的 net.ipv4 外面设置;当 TCP 连贯之后,闲置了tcp_keepalive_time,则会产生侦测包,如果没有收到对方的 ACK,那么会每隔 tcp_keepalive_intvl 再发一次,直到发送了tcp_keepalive_probes,就会抛弃该连贯。
HTTP1.1 和 HTTP2.0 的区别?
HTTP2.0 相比 HTTP1.1 反对的个性:
- 新的二进制格局:HTTP1.1 基于文本格式传输数据;HTTP2.0 采纳二进制格局传输数据,解析更高效。
- 多路复用 :在一个连贯里,容许同时发送多个申请或响应, 并且这些申请或响应可能并行的传输而不被阻塞,防止 HTTP1.1 呈现的”队头梗塞”问题。
- 头部压缩 ,HTTP1.1 的 header 带有大量信息,而且每次都要反复发送;HTTP2.0 把 header 从数据中拆散,并封装成头帧和数据帧, 应用特定算法压缩头帧 ,无效缩小头信息大小。并且 HTTP2.0 在客户端和服务器端记录了之前发送的键值对,对于雷同的数据,不会反复发送。比方申请 a 发送了所有的头信息字段,申请 b 则 只须要发送差别数据,这样能够缩小冗余数据,升高开销。
- 服务端推送:HTTP2.0 容许服务器向客户端推送资源,无需客户端发送申请到服务器获取。
HTTPS 与 HTTP 的区别?
- HTTP 是超文本传输协定,信息是 明文传输 ;HTTPS 则是具备 安全性 的 ssl 加密传输协定。
- HTTP 和 HTTPS 用的端口不一样,HTTP 端口是 80,HTTPS 是 443。
- HTTPS 协定 须要到 CA 机构申请证书,个别须要肯定的费用。
- HTTP 运行在 TCP 协定之上;HTTPS 运行在 SSL 协定之上,SSL 运行在 TCP 协定之上。
什么是数字证书?
服务端能够向证书颁发机构 CA 申请证书,以防止中间人攻打(避免证书被篡改)。证书蕴含三局部内容:证书内容、证书签名算法和签名,签名是为了验证身份。
服务端把证书传输给浏览器,浏览器从证书里取公钥。证书能够证实该公钥对应本网站。
数字签名的制作过程:
- CA 应用证书签名算法对证书内容进行hash 运算。
- 对 hash 后的值 用 CA 的私钥加密,失去数字签名。
浏览器验证过程:
- 获取证书,失去证书内容、证书签名算法和数字签名。
- 用 CA 机构的公钥 对数字签名解密(因为是浏览器信赖的机构,所以浏览器会保留它的公钥)。
- 用证书里的签名算法 对证书内容进行 hash 运算。
- 比拟解密后的数字签名和对证书内容做 hash 运算后失去的哈希值,相等则表明证书可信。
HTTPS 原理
首先是 TCP 三次握手,而后客户端发动一个 HTTPS 连贯建设申请,客户端先发一个 Client Hello
的包,而后服务端响应Server Hello
,接着再给客户端发送它的证书,而后单方通过密钥替换,最初应用替换的密钥加解密数据。
-
协商加密算法 。在
Client Hello
外面客户端会告知服务端本人以后的一些信息,包含客户端要应用的 TLS 版本,反对的加密算法,要拜访的域名,给服务端生成的一个随机数(Nonce)等。须要提前告知服务器想要拜访的域名以便服务器发送相应的域名的证书过去。 -
服务端响应
Server Hello
,通知客户端服务端 选中的加密算法。 -
接着服务端给客户端发来了 2 个证书。第二个证书是第一个证书的签发机构(CA)的证书。
-
客户端应用证书的认证机构 CA 公开公布的 RSA 公钥 对该证书进行验证,下图表明证书认证胜利。
-
验证通过之后,浏览器和服务器通过 密钥替换算法 产生共享的 对称密钥。
-
开始传输数据,应用同一个对称密钥来加解密。
DNS 的解析过程?
- 浏览器搜寻 本人的 DNS 缓存
- 若没有,则搜寻 操作系统中的 DNS 缓存和 hosts 文件
- 若没有,则操作系统将域名发送至 本地域名服务器 ,本地域名服务器查问本人的 DNS 缓存,查找胜利则返回后果,否则顺次向 根域名服务器、顶级域名服务器、权限域名服务器 发动查问申请,最终返回 IP 地址给本地域名服务器
- 本地域名服务器将失去的 IP 地址返回给 操作系统 ,同时本人也 将 IP 地址缓存起来
- 操作系统将 IP 地址返回给浏览器,同时本人也将 IP 地址缓存起来
- 浏览器失去域名对应的 IP 地址
浏览器中输出 URL 返回页面过程?
- 解析域名,找到主机 IP。
- 浏览器利用 IP 间接与网站主机通信,三次握手,建设 TCP 连贯。浏览器会以一个随机端口向服务端的 web 程序 80 端口发动 TCP 的连贯。
- 建设 TCP 连贯后,浏览器向主机发动一个 HTTP 申请。
- 参数从客户端传递到服务器端。
- 服务器端失去客户端参数之后,进行相应的业务解决,再将后果封装成 HTTP 包,返回给客户端。
- 服务器端和客户端的交互实现,断开 TCP 连贯(4 次挥手)。
- 浏览器 解析响应内容,进行渲染,出现给用户。
DNS 域名解析的过程
在网络中定位是依附 IP 进行身份定位的,所以 URL 拜访的第一步便是先要失去服务器端的 IP 地址。而失去服务器的 IP 地址须要应用 DNS(Domain Name System,域名零碎)域名解析,DNS 域名解析就是通过 URL 找到与之绝对应的 IP 地址。
DNS 域名解析的大抵流程如下:
- 先检 查浏览器中的 DNS 缓存,如果浏览器中有对应的记录会间接应用,并实现解析;
- 如果浏览器没有缓存,那就去 查问操作系统的缓存,如果查问到记录就能够间接返回 IP 地址,实现解析;
- 如果操作系统没有 DNS 缓存,就会去 查看本地 host 文件,Windows 操作系统下,host 文件个别位于 “C:\Windows\System32\drivers\etc\hosts”,如果 host 文件有记录则间接应用;
- 如果本地 host 文件没有相应的记录,会 申请本地 DNS 服务器,本地 DNS 服务器个别是由本地网络服务商如挪动、联通等提供。通常状况下可通过 DHCP 主动调配,当然也能够本人手动配置。目前用的比拟多的是谷歌提供的专用 DNS 是 8.8.8.8 和国内的专用 DNS 是 114.114.114.114。
- 如果本地 DNS 服务器没有相应的记录,就会 去根域名服务器查问 了。为了能更高效实现寰球所有域名的解析申请,根域名服务器自身并不会间接去解析域名,而是会把不同的解析申请调配给上面的其余服务器去实现。
图片来源于网络
什么是 cookie 和 session?
因为 HTTP 协定是无状态的协定,须要用某种机制来识具体的用户身份,用来跟踪用户的整个会话。罕用的会话跟踪技术是 cookie 与 session。
cookie就是由服务器发给客户端的非凡信息,而这些信息以文本文件的形式寄存在客户端,而后客户端每次向服务器发送申请的时候都会带上这些非凡的信息。说得更具体一些:当用户应用浏览器拜访一个反对 cookie 的网站的时候,用户会提供包含用户名在内的个人信息并且提交至服务器;接着,服务器在向客户端回传相应的超文本的同时也会发回这些个人信息,当然这些信息并不是寄存在 HTTP 响应体中的,而是寄存于 HTTP 响应头;当客户端浏览器接管到来自服务器的响应之后,浏览器会将这些信息寄存在一个对立的地位。自此,客户端再向服务器发送申请的时候,都会把相应的 cookie 寄存在 HTTP 申请头再次发回至服务器。服务器在接管到来自客户端浏览器的申请之后,就可能通过剖析寄存于申请头的 cookie 失去客户端特有的信息,从而动静生成与该客户端绝对应的内容。网站的登录界面中“请记住我”这样的选项,就是通过 cookie 实现的。
cookie 工作流程:
- servlet 创立 cookie,保留大量数据,发送给浏览器。
- 浏览器取得服务器发送的 cookie 数据,将主动的保留到浏览器端。
- 下次访问时,浏览器将主动携带 cookie 数据发送给服务器。
session 原理:首先浏览器申请服务器拜访 web 站点时,服务器首先会查看这个客户端申请是否曾经蕴含了一个 session 标识、称为 SESSIONID,如果曾经蕴含了一个 sessionid 则阐明以前曾经为此客户端创立过 session,服务器就依照 sessionid 把这个 session 检索进去应用,如果客户端申请不蕴含 session id,则服务器为此客户端创立一个 session,并且生成一个与此 session 相关联的举世无双的 sessionid 寄存到 cookie 中,这个 sessionid 将在本次响应中返回到客户端保留,这样在交互的过程中,浏览器端每次申请时,都会带着这个 sessionid,服务器依据这个 sessionid 就能够找失去对应的 session。以此来达到共享数据的目标。这里须要留神的是,session 不会随着浏览器的敞开而死亡,而是期待超时工夫。
cookie 和 session 的区别?
- 作用范畴不同,Cookie 保留在客户端,Session 保留在服务器端。
- 有效期不同,Cookie 可设置为长时间放弃,比方咱们常常应用的默认登录性能,Session 个别生效工夫较短,客户端敞开或者 Session 超时都会生效。
- 隐衷策略不同,Cookie 存储在客户端,容易被窃取;Session 存储在服务端,安全性绝对 Cookie 要好一些。
- 存储大小不同,单个 Cookie 保留的数据不能超过 4K;对于 Session 来说存储没有下限,但出于对服务器的性能思考,Session 内不要寄存过多的数据,并且须要设置 Session 删除机制。
什么是对称加密和非对称加密?
对称加密 :通信单方应用 雷同的密钥 进行加密。特点是加密速度快,然而毛病是密钥泄露会导致密文数据被破解。常见的对称加密有 AES
和DES
算法。
非对称加密 :它须要生成两个密钥, 公钥和私钥 。公钥是公开的,任何人都能够取得,而私钥是私人保存的。公钥负责加密,私钥负责解密;或者私钥负责加密,公钥负责解密。这种加密算法 安全性更高 ,然而 计算量相比对称加密大很多 ,加密和解密都很慢。常见的非对称算法有RSA
和DSA
。
说说 WebSocket 与 socket 的区别
Socket 是一套规范,它实现了对 TCP/IP 的高度封装,屏蔽网络细节,以不便开发者更好地进行网络编程。Socket 其实就是等于IP 地址 + 端口 + 协定。
WebSocket 是一个长久化的协定,它是随同 H5 而出的协定,用来解决 http 不反对长久化连贯 的问题。
Socket 一个是 网编编程的标准接口,而 WebSocket 则是应用层通信协议。
ARP 协定的工作过程?
ARP 解决了同一个局域网上的主机和路由器 IP 和 MAC 地址的解析。
- 每台主机都会在本人的 ARP 缓冲区中建设一个 ARP 列表,以示意 IP 地址和 MAC 地址的对应关系。
- 当源主机须要将一个数据包要发送到目标主机时,会首先查看本人 ARP 列表中是否存在该 IP 地址对应的 MAC 地址,如果有,就间接将数据包发送到这个 MAC 地址;如果没有,就向本地网段发动一个 ARP 申请的播送包,查问此目标主机对应的 MAC 地址。此 ARP 申请数据包里包含源主机的 IP 地址、硬件地址、以及目标主机的 IP 地址。
- 网络中所有的主机收到这个 ARP 申请后,会查看数据包中的目标 IP 是否和本人的 IP 地址统一。如果不雷同就疏忽此数据包;如果雷同,该主机首先将发送端的 MAC 地址和 IP 地址增加到本人的 ARP 列表中,如果 ARP 表中曾经存在该 IP 的信息,则将其笼罩,而后给源主机发送一个 ARP 响应数据包,通知对方本人是它须要查找的 MAC 地址。
- 源主机收到这个 ARP 响应数据包后,将失去的目标主机的 IP 地址和 MAC 地址增加到本人的 ARP 列表中,并利用此信息开始数据的传输。
- 如果源主机始终没有收到 ARP 响应数据包,示意 ARP 查问失败。
ICMP 协定的性能
ICMP,Internet Control Message Protocol ,Internet 管制音讯协定。
- ICMP 协定是一种面向无连贯的协定,用于传输出错报告管制信息。
- 它是一个十分重要的协定,它对于网络安全具备极其重要的意义。它属于网络层协定,次要用于在主机与路由器之间传递管制信息,包含 报告谬误、替换受限管制和状态信息 等。
- 当遇到 IP 数据无法访问指标、IP 路由器无奈按以后的传输速率转发数据包等状况时,会主动发送 ICMP 音讯。
比方咱们日常应用得比拟多的ping,就是基于 ICMP 的。
什么是 DoS、DDoS、DRDoS 攻打?
- DOS: (Denial of Service), 翻译过去就是拒绝服务, 所有能引起 DOS 行为的攻打都被称为 DOS 攻打。最常见的 DoS 攻打就有 计算机网络宽带攻打 、 连通性攻打。
- DDoS: (Distributed Denial of Service), 翻译过去是分布式拒绝服务。是指处于不同地位的多个攻击者同时向一个或几个指标动员攻打,或者一个攻击者管制了位于不同地位的多台机器并利用这些机器对受害者同时施行攻打。常见的 DDos 有 SYN Flood、Ping of Death、ACK Flood、UDP Flood 等。
- DRDoS: (Distributed Reflection Denial of Service),中文是分布式反射拒绝服务,该形式靠的是发送大量带有被害者 IP 地址的数据包给攻打主机,而后攻打主机对 IP 地址源做出大量回应,从而造成拒绝服务攻打。
什么是 CSRF 攻打,如何防止
CSRF,跨站申请伪造(英文全称是 Cross-site request forgery),是一种挟制用户在以后已登录的 Web 应用程序上执行非本意的操作的攻打办法。
怎么解决 CSRF 攻打呢?
- 查看 Referer 字段。
- 增加校验 token。
什么是 XSS 攻打?
XSS,跨站脚本攻打(Cross-Site Scripting)。它指的是歹意攻击者往 Web 页面里插入歹意 html 代码,当用户浏览该页之时,嵌入其中 Web 外面的 html 代码会被执行,从而达到歹意攻打用户的非凡目标。XSS 攻打个别分三种类型:存储型、反射型、DOM 型 XSS
如何解决 XSS 攻打问题?
- 对输出进行过滤,过滤标签等,只容许非法值。
- HTML 本义
- 对于链接跳转,如
<a href="xxx"
等,要校验内容,禁止以 script 结尾的非法链接。 - 限度输出长度
防盗链
盗链 是指服务提供商本人不提供服务的内容,通过技术手段(能够了解成爬虫)去获取其余网站的资源展现在本人的网站上。常见的盗链有以下几种:图片盗链、音频盗链、视频盗链等。
网站盗链会大量耗费被盗链网站的带宽,而真正的点击率兴许会很小,重大侵害了被盗链网站的利益。
被盗网站就天然会 防盗链,能够通过常常更换图片名,也能够通过检测 referer。因为失常用户拜访一张图片肯定是从本人的网站点击链接进去的,如果一个申请的 referer 是其余网站,就阐明这是一个爬虫。
什么是 Referer?
这里的 Referer 指的是 HTTP 头部的一个字段,也称为 HTTP 起源地址(HTTP Referer),用来示意从哪儿链接到目前的网页,采纳的格局是 URL。换句话说,借着 HTTP Referer 头部网页能够查看访客从哪里而来,这也常被用来凑合伪造的跨网站申请。
盗链网站会针对性进行 反盗链 ,能够通过在申请的 headers 中设置 referer 来绕过 防盗链,咱们当初应用爬虫抓取他人的网站也是这样。
什么是空 Referer,什么时候会呈现空 Referer?
首先,咱们对空 Referer 的定义为,Referer 头部的内容为空,或者,一个 HTTP 申请中基本不蕴含 Referer 头部。
那么什么时候 HTTP 申请会不蕴含 Referer 字段呢?依据 Referer 的定义,它的作用是批示一个申请是从哪里链接过去,那么当一个申请并不是由链接触发产生的,那么天然也就不须要指定这个申请的链接起源。
比方,间接在浏览器的地址栏中输出一个资源的 URL 地址,那么这种申请是不会蕴含 Referer 字段的,因为这是一个“凭空产生”的 HTTP 申请,并不是从一个中央链接过来的。
说下 ping 的原理
ping,Packet Internet Groper,是一种因特网包摸索器,用于测试网络连接量的程序。Ping 是工作在 TCP/IP 网络体系结构中应用层的一个服务命令,次要是向特定的目标主机发送 ICMP(Internet Control Message Protocol 因特网报文控制协议)申请报文,测试目标站是否可达及理解其无关状态。
一般来说,ping 能够用来检测网络通不通。它是基于 ICMP
协定工作的。假如 机器 A ping机器 B ,工作过程如下:
- ping 告诉零碎,新建一个固定格局的 ICMP 申请数据包
- ICMP 协定,将该数据包和指标机器 B 的 IP 地址打包,一起转交给 IP 协定层
- IP 层协定将本机 IP 地址为源地址,机器 B 的 IP 地址为指标地址,加上一些其余的管制信息,构建一个 IP 数据包
- 先获取指标机器 B 的 MAC 地址。
- 数据链路层构建一个数据帧,目标地址是 IP 层传过来的MAC 地址,源地址是本机的MAC 地址
- 机器 B 收到后,比照指标地址,和本人本机的 MAC 地址是否统一,合乎就解决返回,不合乎就抛弃。
- 依据目标主机返回的 ICMP 回送答复报文中的工夫戳,从而计算出往返工夫
- 最终显示后果有这几项:发送到目标主机的 IP 地址、发送 & 收到 & 失落的分组数、往返工夫的最小、最大 & 平均值