• HTTP面试题总结


    什么是HTTP? HTTP 和 HTTPS 的区别?

    http:超文本运输协议,是实现网络通信的一种规范,在计算机和网络世界中,存在不同的协议,入广播协议,寻址协议,路由协议等等

    在实际应用中,http经常被用于在web浏览器和网站服务器之间传递信息,以明文方式发送内容,不提供任何方式的数据加密

    http的特点:

    支持客户/服务器模式

    简单快速,客户相服务器请求服务时,只需要传送请求方法和路径,由于http协议很简单,使得http服务器的程序规模小,因此通信速度快

    灵活:http允许传输任意类型的数据对象,正在传输的类型由Content-Type加以标记

    无连接:无连接的含义是限制每次连接只处理一个请求,服务器处理完客户的请求,并收到客户的应答后,立即断开连接,采用这种方式可以节省传输时间

    无状态:http协议无法根据之间的状态进行本次的请求处理

    https

     由于http是以明文的形式发送内容,很不安全,https的出现就是为了解决这一问题

    HTTPS=HTTP+SSL/TLS

    通过SSL来验证服务器的身份,并且在浏览器和服务器之间进行加密操作

    SSL协议位于TCP/IP协议与各种应用程协议之间,浏览器和服务器在使用SSL建立连接时需要选择一组恰当的加密算法来实现安全通信,为数据通讯提供安全支持

    执行流程如下:

    • 首先客户端通过URL访问服务器建立SSL连接
    • 服务端收到客户端请求后,会将网站支持的证书信息(证书中包含公钥)传送一份给客户端
    • 客户端的服务器开始协商SSL连接的安全等级,也就是信息加密的等级
    • 客户端的浏览器根据双方同意的安全等级,建立会话密钥,然后利用网站的公钥将会话密钥加密,并传送给网站
    • 服务器利用自己的私钥解密出会话密钥
    • 服务器利用会话密钥加密与客户端之间的通信

    区别

    • HTTPS是HTTP协议的安全版本,HTTP协议的数据传输是明文的,是不安全的,HTTPS使用了SSL/TLS协议进行了加密处理,相对更安全
    • HTTP 和 HTTPS 使用连接方式不同,默认端口也不一样,HTTP是80,HTTPS是443
    • HTTPS 由于需要设计加密以及多次握手,性能方面不如 HTTP
    • HTTPS需要SSL,SSL 证书需要钱,功能越强大的证书费用越高

     为什么说HTTPS比HTTP安全? HTTPS是如何保证安全的?

    在http通信中,存在以下问题:

    • 通信使用明文(不加密),内容可能被窃听
    • 不验证通信方的身份,因此有可能遭遇伪装

     HTTPS是建立在SSL之上,他的安全性由SSL来保证

    有了SSL,HTTP就拥有了HTTPS的加密、证书和完整性的保护功能

    SSL依赖功能:

    对称加密:采用协商的密钥对数据加密

    对称加密指的是加密和解密使用的密钥是同一个,是对称的

    非对称加密:实现身份认证和密钥协商

    非对称加密,存在两个密钥,一个叫公钥,一个叫私钥,两个秘钥是不同的,公钥可以公开给任何人使用,私钥则需要保密

    摘要算法:验证信息的完整性

    对称加密+非对称加密

    数字签名:身份验证

    数字签名能确定消息确实是由发送方签名并发出来的,因为别人假冒不了发送方的签名

    原理其实很简单,就是用私钥加密,公钥解密

    总结:

    可以看到,HTTPSHTTP虽然只差一个SSL,但是通信安全得到了大大的保障,通信的四大特性都以解决,解决方式如下:

    • 机密性:混合算法
    • 完整性:摘要算法
    • 身份认证:数字签名
    • 不可否定:数字签名

    同时引入第三方证书机构,确保公开秘钥的安全性

    如何理解UDP 和 TCP? 区别? 应用场景?

     UDP(User Datagram Protocol),用户数据包协议,是一个简单的面向数据报的通信协议,即对应用层交下来的报文,不合并,不拆分,只是在其上面加上首部后就交给了下面的网络层

    无论应用层层交给UDP多长的报文,它统统发送,一次发送一个报文

    UDP报头包括4个字段,每个字段占用2个字节(即16个二进制位),标题短,开销小

    特点:

    • UDP 不提供复杂的控制机制,利用 IP 提供面向无连接的通信服务
    • 传输途中出现丢包,UDP 也不负责重发
    • 当包的到达顺序出现乱序时,UDP没有纠正的功能。
    • 并且它是将应用程序发来的数据在收到的那一刻,立即按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况,UDP 也无法进行流量控制等避免网络拥塞行为

    tcp 

     TCP(Transmission Control Protocol),传输控制协议,是一种可靠、面向字节流的通信协议,把上面应用层交下来的数据看成无结构的字节流来发送

    可以想象成流水形式的,发送方TCP会将数据放入”蓄水池(缓存区)“,等到可以发送的时候就发送,不能发送就等着

    tcp报文首部有20个字节,额外开销大

    特点:

    • TCP充分地实现了数据传输时各种控制功能,可以进行丢包时的重发控制,还可以对次序乱掉的分包进行顺序控制。而这些在 UDP 中都没有。
    • 此外,TCP 作为一种面向有连接的协议,只有在确认通信对端存在时才会发送数据,从而可以控制通信流量的浪费。
    • 根据 TCP 的这些机制,在 IP 这种无连接的网络上也能够实现高可靠性的通信( 主要通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现)

    区别:

    • TCP 是面向连接的协议,建立连接3次握手、断开连接四次挥手,UDP是面向无连接,数据传输前后不连接连接,发送端只负责将数据发送到网络,接收端从消息队列读取

    • TCP 提供可靠的服务,传输过程采用流量控制、编号与确认、计时器等手段确保数据无差错,不丢失。UDP 则尽可能传递数据,但不保证传递交付给对方

    • TCP 面向字节流,将应用层报文看成一串无结构的字节流,分解为多个TCP报文段传输后,在目的站重新装配。UDP协议面向报文,不拆分应用层报文,只保留报文边界,一次发送一个报文,接收方去除报文首部后,原封不动将报文交给上层应用

    • TCP 只能点对点全双工通信。UDP 支持一对一、一对多、多对一和多对多的交互通信

     场景:

     如何理解OSI七层模型?

    OSI模型全称为开放式通信系统互联参考模型,是国际标准化组织提出的一个试图使各种计算机在世界范围内互联为网络的标准框架

     OSI将计算机网络体系结构划分为七层,每一层实现各自的功能和协议,并完成与相邻层的接口通信。即每一层扮演固定的角色,互不打扰

     划分:

    划分为了七层模型:

    应用层、位于第七层,作用是通过应用程序间的交互来完成特定的网络应用

    表示层、作用是使通信的应用程序能够解释交换数据的含义

    会话层、负责建立、管理和终止表达层实体之间的通信会话

    传输层、主要的任务是为两台主机进程之间的通信提供服务

    网络层、主要任务就是选择合适的网间路由和交换节点,确保数据按时成功传送

    数据链路层、也叫链路层,在物理层和网络层之间,两台主机之间的数据传输

    物理层:实现计算机节点之间比特流的透明传送

    传输过程:

    • 应用层报文被传送到运输层
    • 在最简单的情况下,运输层收取到报文并附上附加信息,该首部将被接收端的运输层使用
    • 应用层报文和运输层首部信息一道构成了运输层报文段。附加的信息可能包括:允许接收端运输层向上向适当的应用程序交付报文的信息以及差错检测位信息。该信息让接收端能够判断报文中的比特是否在途中已被改变
    • 运输层则向网络层传递该报文段,网络层增加了如源和目的端系统地址等网络层首部信息,生成了网络层数据报
    • 网络层数据报接下来被传递给链路层,在数据链路层数据包添加发送端 MAC 地址和接收端 MAC 地址后被封装成数据帧
    • 在物理层数据帧被封装成比特流,之后通过传输介质传送到对端
    • 对端再一步步解开封装,获取到传送的数据

    如何理解TCP/IP协议? 

     TCP/IP,传输控制协议/网际协议,是指能够在多个不同网络间实现信息传输的协议簇

    • TCP(传输控制协议)

    一种面向连接的、可靠的、基于字节流的传输层通信协议

    • IP(网际协议)

    用于封包交换数据网络的协议

    TCP/IP协议不仅仅指的是TCPIP两个协议,而是指一个由FTPSMTPTCPUDPIP等协议构成的协议簇

    TCP/IP协议族按层次分别了五层体系或者四层体系

    五层体系的协议结构是综合了 OSI 和 TCP/IP 优点的一种协议,包括应用层、传输层、网络层、数据链路层和物理层

    五层协议的体系结构只是为介绍网络原理而设计的,实际应用还是 TCP/IP 四层体系结构,包括应用层、传输层、网络层(网际互联层)、网络接口层

     

    总结:

    相同点:

    • OSI 参考模型与 TCP/IP 参考模型都采用了层次结构
    • 都能够提供面向连接和无连接两种通信服务机制

    不同点:

    • OSI 采用的七层模型; TCP/IP 是四层或五层结构

    • TCP/IP 参考模型没有对网络接口层进行细分,只是一些概念性的描述; OSI 参考模型对服务和协议做了明确的区分

    • OSI 参考模型虽然网络划分为七层,但实现起来较困难。TCP/IP 参考模型作为一种简化的分层结构是可以的

    • TCP/IP协议去掉表示层和会话层的原因在于会话层、表示层、应用层都是在应用程序内部实现的,最终产出的是一个应用数据包,而应用程序之间是几乎无法实现代码的抽象共享的,这也就造成 OSI 设想中的应用程序维度的分层是无法实现的

     DNS协议 是什么?说说DNS 完整的查询过程?

    DNS域名系统,是互联网一项服务,是进行域名和与之相对应的ip地址进行转换的服务器

    dns相当于是一个翻译官,负责将域名翻译称ip地址

    IP:一长串能够唯一地标记网络上的计算机的数字

    域名:是由一串用点分割的名字组成的internet上某台计算机和计算机组的名称,用于在数据传输时对计算机的定位标识

    域名: 

    域名是一个具有层次的结构,从上到下一次为根域名,顶级域名,二级域名,三级域名,在域名的每一层都会有一个域名服务器

    查询方式:

     递归查询:如果 A 请求 B,那么 B 作为请求的接收者一定要给 A 想要的答案

    迭代查询:如果接收者 B 没有请求者 A 所需要的准确内容,接收者 B 将告诉请求者 A,如何去获得这个内容,但是自己并不去发出请求

    域名缓存:

    计算机中DNS的记录也分成了两种缓存方式:

    • 浏览器缓存:浏览器在获取网站域名的实际 IP 地址后会对其进行缓存,减少网络请求的损耗
    • 操作系统缓存:操作系统的缓存其实是用户自己配置的 hosts 文件

    查询过程:

    解析域名的过程如下:

    • 首先搜索浏览器的 DNS 缓存,缓存中维护一张域名与 IP 地址的对应表

    • 若没有命中,则继续搜索操作系统的 DNS 缓存

    • 若仍然没有命中,则操作系统将域名发送至本地域名服务器,本地域名服务器采用递归查询自己的 DNS 缓存,查找成功则返回结果

    • 若本地域名服务器的 DNS 缓存没有命中,则本地域名服务器向上级域名服务器进行迭代查询

      • 首先本地域名服务器向根域名服务器发起请求,根域名服务器返回顶级域名服务器的地址给本地服务器
      • 本地域名服务器拿到这个顶级域名服务器的地址后,就向其发起请求,获取权限域名服务器的地址
      • 本地域名服务器根据权限域名服务器的地址向其发起请求,最终得到该域名对应的 IP 地址
    • 本地域名服务器将得到的 IP 地址返回给操作系统,同时自己将 IP 地址缓存起来

    • 操作系统将 IP 地址返回给浏览器,同时自己也将 IP 地址缓存起

    • 至此,浏览器就得到了域名对应的 IP 地址,并将 IP 地址缓存起

    如何理解CDN?说说实现原理?

    CDN,内容分发网络,构建在现有网络基础之上的智能虚拟网络,依靠部署在各地的边缘服务器,通过中心平台的负载均衡,内容分发,调度等功能模块

    CDN的管家技术主要有内容存储和分发技术

    CDN就是根据用户位置分配最近的资源

    原理分析:

    在没有应用CDN时,我们使用域名访问某一个站点时的路径是

    用户提交域名→浏览器对域名进行解释→DNS 解析得到目的主机的IP地址→根据IP地址访问发出请求→得到请求数据并回复

    应用CDN后,DNS返回的不再是IP地址,而是一个CNAME别名记录,指向CDN的全局负载均衡

    CNAME实际上在域名解析的过程中承担了中间人(或者说代理)的角色,这是CDN实现的关键

    负载均衡系统:

    由于没有返回IP地址,于是本地DNS会向负载均衡系统再发送请求 ,则进入到CDN的全局负载均衡系统进行智能调度

    缓存代理:

     缓存系统是 CDN的另一个关键组成部分,缓存系统会有选择地缓存那些最常用的那些资源

    总结:

    CDN 目的是为了改善互联网的服务质量,通俗一点说其实就是提高访问速度

    CDN 构建了全国、全球级别的专网,让用户就近访问专网里的边缘节点,降低了传输延迟,实现了网站加速

    通过CDN的负载均衡系统,智能调度边缘节点提供服务,相当于CDN服务的大脑,而缓存系统相当于CDN的心脏,缓存命中直接返回给用户,否则回源

     说说 HTTP1.0/1.1/2.0 的区别?

    HTTP1.0

    HTTP 1.0 浏览器与服务器只保持短暂的连接,每次请求都需要与服务器建立一个TCP连接

    服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求

     HTTP1.1

    HTTP1.1中,默认支持长连接(Connection: keep-alive),即在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟

    建立一次连接,多次请求均由这个连接完成

    HTTP2.0

    HTTP2.0在相比之前版本,性能上有很大的提升,如添加了一个特性:

    • 多路复用:HTTP/2 复用TCP连接,在一个连接里,客户端和浏览器都可以同时发送多个请求或回应,而且不用按照顺序一一对应,这样就避免了”队头堵塞”
    • 二进制分帧:每个数据流都以消息的形式发送,而消息又由一个或多个帧组成。多个帧之间可以乱序发送,根据帧首部的流标识可以重新组装,这也是多路复用同时发送数据的实现条件
    • 首部压缩:HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对,对于相同的数据,不再通过每次请求和响应发送
    • 服务器推送:HTTP2引入服务器推送,允许服务端推送资源给客户端

    总结:

    HTTP1.0:

    • 浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接

    HTTP1.1:

    • 引入了持久连接,即TCP连接默认不关闭,可以被多个请求复用
    • 在同一个TCP连接里面,客户端可以同时发送多个请求
    • 虽然允许复用TCP连接,但是同一个TCP连接里面,所有的数据通信是按次序进行的,服务器只有处理完一个请求,才会接着处理下一个请求。如果前面的处理特别慢,后面就会有许多请求排队等着
    • 新增了一些请求方法
    • 新增了一些请求头和响应头

    HTTP2.0:

    • 采用二进制格式而非文本格式
    • 完全多路复用,而非有序并阻塞的、只需一个连接即可实现并行
    • 使用报头压缩,降低开销
    • 服务器推送

    说说HTTP 常见的状态码有哪些,适用场景? 

    http状态码,用以表示网页服务器超文本传输协议响应状态的3为数字代码

    http状态码的作用是服务器告诉客户端当前请求响应的状态,通过状态码就能判断和分析服务器的运行状态

    分类:

    1 表示消息:请求已经被接收,需要继续处理,响应是临时响应

    100:客户端继续发送请求,临时响应,是用来通知客户端它的部分请求已经被服务器接收,切没有被拒绝,客户端应当继续发送请求的剩余部分

    101:服务器根据客户端的请求切换协议,主要用于webpack或HTTP2升级

    2 表示成功:代表请求已成功被服务器接收、理解、并接收

    • 200(成功):请求已成功,请求所希望的响应头或数据体将随此响应返回

    • 201(已创建):请求成功并且服务器创建了新的资源

    • 202(已创建):服务器已经接收请求,但尚未处理

    • 203(非授权信息):服务器已成功处理请求,但返回的信息可能来自另一来源

    • 204(无内容):服务器成功处理请求,但没有返回任何内容

    • 205(重置内容):服务器成功处理请求,但没有返回任何内容

    • 206(部分内容):服务器成功处理了部分请求

    3 表示重定向:表示要完成请求,需要进一步操作。 通常,这些状态代码用来重定向

    • 300(多种选择):针对请求,服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作,或提供操作列表供请求者选择

    • 301(永久移动):请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置

    • 302(临时移动): 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求

    • 303(查看其他位置):请求者应当对不同的位置使用单独的 GET 请求来检索响应时,服务器返回此代码

    • 305 (使用代理): 请求者只能使用代理访问请求的网页。 如果服务器返回此响应,还表示请求者应使用代理

    • 307 (临时重定向): 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求

    4 表示请求错误:代表了客户端看起来可能发生了错误,妨碍了服务器的处理

    • 400(错误请求): 服务器不理解请求的语法
    • 401(未授权): 请求要求身份验证。 对于需要登录的网页,服务器可能返回此响应。
    • 403(禁止): 服务器拒绝请求
    • 404(未找到): 服务器找不到请求的网页
    • 405(方法禁用): 禁用请求中指定的方法
    • 406(不接受): 无法使用请求的内容特性响应请求的网页
    • 407(需要代理授权): 此状态代码与 401(未授权)类似,但指定请求者应当授权使用代理
    • 408(请求超时): 服务器等候请求时发生超时

    5 表示服务器错误:表示服务器无法完成明显有效的请求。这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生

    • 500(服务器内部错误):服务器遇到错误,无法完成请求
    • 501(尚未实施):服务器不具备完成请求的功能。 例如,服务器无法识别请求方法时可能会返回此代码
    • 502(错误网关): 服务器作为网关或代理,从上游服务器收到无效响应
    • 503(服务不可用): 服务器目前无法使用(由于超载或停机维护)
    • 504(网关超时): 服务器作为网关或代理,但是没有及时从上游服务器收到请求
    • 505(HTTP 版本不受支持): 服务器不支持请求中所用的 HTTP 协议版本

    说一下 GET 和 POST 的区别? 

     GETPOST,两者是HTTP协议中发送请求的方法

    GET方法请求一个指定资源的表示形式,使用GET的请求应该只被用于获取数据

    POST方法用于将实体提交到指定的资源,通常导致在服务器上的状态变化或副作用

    区别:

    • GET在浏览器回退时是无害的,而POST会再次提交请求。
    • GET产生的URL地址可以被Bookmark,而POST不可以。
    • GET请求会被浏览器主动cache,而POST不会,除非手动设置。
    • GET请求只能进行url编码,而POST支持多种编码方式。
    • GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
    • GET请求在URL中传送的参数是有长度限制的,而POST没有。
    • 对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
    • GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。
    • GET参数通过URL传递,POST放在Request body中

     说说 HTTP 常见的请求头有哪些? 作用

    是什么?

     超文本传输协议的请求和响应消息中的消息头部分,它定义了一个超文本传输协议事务种的操作参数

    HTTP头部字段可以自己根据需要定义,因此可能在web服务器和浏览器上发现非标准的头字段

    分类:

    字段名说明示例
    Accept能够接受的回应内容类型(Content-Types)Accept: text/plain
    Accept-Charset能够接受的字符集Accept-Charset: utf-8
    Accept-Encoding能够接受的编码方式列表Accept-Encoding: gzip, deflate
    Accept-Language能够接受的回应内容的自然语言列表Accept-Language: en-US
    Authorization用于超文本传输协议的认证的认证信息Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
    Cache-Control用来指定在这次的请求/响应链中的所有缓存机制 都必须 遵守的指令Cache-Control: no-cache
    Connection该浏览器想要优先使用的连接类型Connection: keep-alive Connection: Upgrade
    Cookie服务器通过 Set- Cookie (下文详述)发送的一个 超文本传输协议CookieCookie: $Version=1; Skin=new;
    Content-Length以 八位字节数组 (8位的字节)表示的请求体的长度Content-Length: 348
    Content-Type请求体的 多媒体类型Content-Type: application/x-www-form-urlencoded
    Date发送该消息的日期和时间Date: Tue, 15 Nov 1994 08:12:31 GMT
    Expect表明客户端要求服务器做出特定的行为Expect: 100-continue
    Host服务器的域名(用于虚拟主机 ),以及服务器所监听的传输控制协议端口号Host: en.wikipedia.org:80 Host: en.wikipedia.org
    If-Match仅当客户端提供的实体与服务器上对应的实体相匹配时,才进行对应的操作。主要作用时,用作像 PUT 这样的方法中,仅当从用户上次更新某个资源以来,该资源未被修改的情况下,才更新该资源If-Match: "737060cd8c284d8af7ad3082f209582d"
    If-Modified-Since允许在对应的内容未被修改的情况下返回304未修改If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    If-None-Match允许在对应的内容未被修改的情况下返回304未修改If-None-Match: "737060cd8c284d8af7ad3082f209582d"
    If-Range如果该实体未被修改过,则向我发送我所缺少的那一个或多个部分;否则,发送整个新的实体If-Range: "737060cd8c284d8af7ad3082f209582d"
    Range仅请求某个实体的一部分Range: bytes=500-999
    User-Agent浏览器的浏览器身份标识字符串User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0
    Origin发起一个针对 跨来源资源共享 的请求Origin: http://www.example-social-network.com

     使用场景:

    协商缓存

    会话状态

    说说地址栏输入 URL 敲下回车后发生了什么?

    • URL解析
    • DNS 查询
    • TCP 连接
    • HTTP 请求
    • 响应请求
    • 页面渲染

    详细步骤分析:

    输入url后,首先会去进行域名解析为ip地址
    客户端根据ip地址去寻找相应的服务器
    然后与服务器进行TCP的三次握手。所谓三次握手,就是客户端在请求与服务端连接时,彼此共计发送了三次数据包。
    客户端找到相应的资源库
    根据资源库返回页面信息
    浏览器根据自身的执行机制解析页面
    最后服务器将解析信息返回给客户端,进行TCP四次挥手
    客户端显示自己的请求,即服务端返回的东西

    说说TCP为什么需要三次握手和四次挥手

    三次握手

     三次握手(Three-way Handshake)其实就是指建立一个TCP连接时,需要客户端和服务器总共发送3个包

    主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备

    • 第一次握手:客户端给服务端发一个 SYN 报文,并指明客户端的初始化序列号 ISN(c),此时客户端处于 SYN_SENT 状态
    • 第二次握手:服务器收到客户端的 SYN 报文之后,会以自己的 SYN 报文作为应答,为了确认客户端的 SYN,将客户端的 ISN+1作为ACK的值,此时服务器处于 SYN_RCVD 的状态
    • 第三次握手:客户端收到 SYN 报文之后,会发送一个 ACK 报文,值为服务器的ISN+1。此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后,也处于 ESTABLISHED 状态,此时,双方已建立起了连接

     握手的作用:

    • 第一次握手:客户端发送网络包,服务端收到了 这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。
    • 第二次握手:服务端发包,客户端收到了 这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常
    • 第三次握手:客户端发包,服务端收到了。 这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常

    四次挥手

     tcp终止一个连接,需要经过四次挥手

     挥手过程:

    • 第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态,停止发送数据,等待服务端的确认
    • 第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 +1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT状态
    • 第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态
    • 第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态,服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态

    挥手原因:

    服务端在收到客户端断开连接Fin报文后,并不会立即关闭连接,而是先发送一个ACK包先告诉客户端收到关闭连接的请求,只有当服务器的所有报文发送完毕之后,才发送FIN报文断开连接,因此需要四次挥手

    说说对WebSocket的理解?应用场景?

    是什么?

    WebSocket,是一种网络传输协议,位于OSI模型的应用层。可在单个TCP连接上进行全双工通信,能更好的节省服务器资源和带宽并达到实时通迅

    客户端和服务器只需要完成一次握手,两者之间就可以创建持久性的连接,并进行双向数据传输

    特点:

    全双工:通信允许数据在两个方向上同时传输,它在能力上相当于两个单工通信方式的结合

    二进制帧: 采用了二进制帧结构,语法、语义与 HTTP 完全不兼容,相比http/2WebSocket更侧重于“实时通信”,而HTTP/2 更侧重于提高传输效率,所以两者的帧结构也有很大的区别

    协议名:引入wswss分别代表明文和密文的websocket协议,且默认端口使用80或443,几乎与http一致

    握手:WebSocket也要有一个握手过程,然后才能正式收发数据

    优点:

    • 较少的控制开销:数据包头部协议较小,不同于http每次请求需要携带完整的头部
    • 更强的实时性:相对于HTTP请求需要等待客户端发起请求服务端才能响应,延迟明显更少
    • 保持创连接状态:创建通信后,可省略状态信息,不同于HTTP每次请求需要携带身份验证
    • 更好的二进制支持:定义了二进制帧,更好处理二进制内容
    • 支持扩展:用户可以扩展websocket协议、实现部分自定义的子协议
    • 更好的压缩效果:Websocket在适当的扩展支持下,可以沿用之前内容的上下文,在传递类似的数据时,可以显著地提高压缩率

     应用场景:

    • 弹幕
    • 媒体聊天
    • 协同编辑
    • 基于位置的应用
    • 体育实况更新
    • 股票基金报价实时更新
  • 相关阅读:
    redis的常用基础类型及操作
    python3-循环与条件语句
    数据分析之金融数据分析
    .NET微服务系统迁移至.NET6.0的故事
    Shell echo、printf、test命令
    security如何不拦截websocket
    Python爬虫实战(实战篇)—17获取【CSDN某一专栏】数据转为Markdown列表放入文章中
    1000套安卓(Android)毕业设计(带论文)、大作业、实例快速下载 (Android Studio)
    shell获取应用程序和函数的返回值
    由面试题“Redis是否为单线程”引发的思考
  • 原文地址:https://blog.csdn.net/qq_60976312/article/details/127651831