索引
OSI七层模型(Open System Interconnect)
-
物理层
主要定义物理设备的标准,如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等(集线器、中继器、调制解调器、网线、双绞线、同轴电缆等)。它的主要作用是传输比特流(就是有0、1转化为电流强弱来进行传输,到达目的地后转化为0、1,也就是我们常说的数模转换与模数转换),这一层的数据叫做比特。
-
数据链路层
将比特组合成字节,再将字节组合成帧,使用链路层地址(以太网使用MAC地址)来访问介质,并进行差错检测。本层定义了如何让格式化数据以进行传输,以及如何让控制对物理介质的访问,这一层通常还提供错误检测和纠正,以保证数据的可靠传输。数据链路层又分为2个子层:
- 逻辑链路控制子层(LLC)
LLC层定义了一些字段使用上次协议能共享数据链路层,实际使用中,LLC层非必需 - 媒体访问控制子层(MAC)
MAC层处理CSMA/CD算法、数据出错校验、成帧等
- 逻辑链路控制子层(LLC)
-
网络层
通过IP寻址来建立两个节点的之间的连接,为源端的运输层送来分组,选择合适的路由和交换节点,正确无误的传送给目的端的运输层,这一层也就是我们经常说的IP协议层。IP协议是Internet的基础。
-
传输层
定义了一些传输数据的协议和端口(web服务80等),如TCP(传输控制协议,传输效率低,可靠性强,用于传输可靠性要求高,数据量大的数据)、UDP(用户数据报协议,与TCP协议恰恰相反,用户传输可靠性要求不高,数据量小的数据,如即时通讯应用聊天数据传输),将从下层接收到的数据进行分段和传输,到达目的地址后再进行重组,此层数据通常称作段。
-
会话层
通过传输层(端口号,传输端口号和接收端口号)建立数据传输通路,主要在系统之间发起会话或者接收会话请求(设备之间需要互相识别,可以通过IP、MAC、主机名)。
-
表示层
提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层所识别。如有必要,表示层可提供一种标准表示形式,用户将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩、加密是表示层提供的转换功能之一。
-
应用层
最靠近用户的一层,为用户的应用程序提供各种网络服务。常见的应用层网络协议有:HTTP、HTTPS、FTP、POP3、SMTP、Telnet、DNS。
TCP/IP五层模型
- 物理层
- 数据链路层
- 网络层
- 传输层
- 应用层
TCP/IP四层概念模型
- 数据链路层
- 网络层
- 传输层
- 应用层
OSI七层模型 | TCP/IP四层概念模型 | 对应网络协议 |
---|---|---|
应用层(Application) | 应用层 | HTTP、HTTPS、FTP、NFS、SMTP、WAIS、TFTP |
表示层(Presentation) | Telnet、Rlogin、SNMP、Gopher | |
会话层(Session) | SMTP、DNS | |
传输层(Transport) | 传输层 | TCP、UDP |
网络层(Network) | 网络层 | IP、ICMP、ARP、RARP、AKP、UUCP |
数据链路层(Data Link) | 数据链路层 | FDDI、Ethernet、Arpanet、PDN、SLIP、PPP |
物理层(Physical) | IEEE 802.1A, IEEE 802.2到IEEE 802.11 |
TCP(传输控制协议)
特点:
- TCP是面向连接的运输层协议,应用程序在使用TCP协议前,必须建立TCP连接;在传输数据完毕后,必须释放已经建立的TCP连接。
- 每一条TCP连接只能有两个端点,并且只能是点对点(一对一)
- TCP提供可靠交付的服务。通过TCP连接传输的数据,无差错、不丢失、不重复,并且按序到达。
- TCP提供全双工通信。TCP允许通信双方的应用程序在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存,用来临时存放双向通信的数据。在发送时,应用程序在把数据传送给TCP缓存后,就可以做自己的事,而TCP在合适的时候把数据发送出去。在接收时,TCP把收到的数据放入缓存,上层应用进程在合适的时候读取缓存中的数据。
- 面向字节流 。
UDP(用户数据报协议)
特点:
- UDP是无连接的,即发送数据之前不需要建立连接(当然,发送数据结束时也没有连接可释放),因此减小了开销和发送数据之前的时延。
- UDP使用尽最大努力交付, 即不保证可靠交付, 因此主机不需要维持复杂的连接状态表(这里面有许多参数)
- UDP是面向报文的。发送方的UDP对应用程序交下来的报文, 在添加首部后就向下交付IP层(网络层)。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。
- UDP没有拥塞控制,因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用(如IP电话、实时视频会议等)很重要。
- UDP支持一对一、一对多、多对一、多对多的交互通信。
- UDP首部开销小,只有8个字节,比TCP的20个字节的首部要短。
TCP三次握手(三报文握手)
- 服务器器进程先创建传输控制块TCB,并处于监听状态,等待客户端的连接请求;
- 客户端创建传输控制块TCB,并向服务器发出连接请求报文段;
- 服务器端收到请求报文段后,如同意建立连接,则发送确认报文段;
- 客户端进程接收到服务器的确认报文段后,立即回复确认报文段,并进入已建立连接状态;
- 服务器收到确认报文段后,也进入已建立连接状态。
- 第一次握手:Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给Server,Client进入SYN_SENT状态,等待Server确认。
- 第二次握手: Server 收到数据包后由标志位 SYN=1 知道 Client 请求建立连接, Server 将标志位 SYN 和 ACK 都置为 1 , ack=J+1 ,随机产生一个值 seq=K ,并将该数据包发送给 Client 以确认连接请求, Server 进入 SYN_RCVD 状态。
- 第三次握手: Client 收到确认后,检查 ack 是否为 J+1 , ACK 是否为 1 ,如果正确则将标志位 ACK 置为 1 , ack=K+1 ,并将该数据包发送给 Server , Server 检查 ack 是否为 K+1 , ACK 是否为 1 ,如果正确则连接建立成功, Client 和 Server 进入 ESTABLISHED 状态,完成三次握手,随后 Client 与 Server 之间可以开始传输数据了。
TCP四次挥手
- 第一次挥手:客户端发送一个FIN,用来关闭客户端到服务器的数据传送,客户端进入FIN_WAIT_1状态;
- 第二次挥手:服务器收到FIN后,发送一个ACK给客户端,确认序号为收到序号 +1(与SYN相同, 一个FIN占用一个序号),服务器进入CLOSE_WAIT状态;
- 第三次挥手:服务器发送一个FIN,用来关闭服务器到客户端的数据传送,服务器进入LAST_ACK状态;
- 第四次挥手:客户端收到来自服务器的FIN后,客户端进入TIME_WAIT状态,经过时间等待计时器设置的时间 2MSL 后,进入 CLOSED(关闭) 状态,接着发送一个ACK给服务器,确认序号为收到序号 +1,服务器收到客户端报文段后,服务器进入CLOSED状态,完成四次挥手。
字段说明:
- 序号:Seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。
- 确认序号:Ack序号,占32位,只有ACK标志位为1时,确认序号字段才有效,Ack=Seq+1。
- 标志位:共6个,即URG、ACK、PSH、RST、SYN、FIN等,具体含义如下:
– URG:紧急指针(urgent pointer)有效。
– ACK:确认序号有效。
– PSH:接收方应该尽快将这个报文交给应用层。
– RST:重置连接。
– SYN:发起一个新连接。
– FIN:释放一个连接。
HTTP状态码
-
概念
HTTP 状态码用来告诉客户端,发生了什么事情,状态码位于响应的起始行中
-
分类
状态码 | 整体范围 | 已定义范围 | 类别 |
---|---|---|---|
1XX | 100~199 | 100~101 | 信息提示 |
2XX | 200~299 | 200~206 | 成功 |
3XX | 300~399 | 300~305 | 重定向 |
4XX | 400~499 | 400~415 | 客户端错误 |
5XX | 500~599 | 500~505 | 服务器错误 |
- 常见状态码
状态码 | 英文语义 | 中文描述 | 出现概率 |
---|---|---|---|
100 | Continue | 继续。客户端应继续其请求 | * |
101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到HTTP的新版本协议 | * |
200 | OK | 请求成功 | *** |
201 | Created | 已创建。成功请求并创建了新的资源 | * |
202 | Accepted | 已接受。已经接收请求,但未处理完成 | * |
203 | Non-Authoritative Information | 非授权信息。请求成功,但返回的meta信息不在原始服务器,而是一个副本 | * |
204 | No Content | 无内容。服务器成功处理,但未返回内容,在未更新网页的情况下,可确保浏览器继续显示当前文档 | * |
205 | Reset Content | 重置内容。服务器处理成功,用户终端(如浏览器)应重置文档视图,可通过此返回状态码清除浏览器的表单域 | * |
206 | Partial Centent | 部分内容。服务器成功处理了部分GET请求 | * |
300 | Mutiple Choices | 多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(如浏览器)选择 | * |
301 | Moved Permanently | 永久移动。请求资源已被永久的移动到新的URI,返回信息会包括新的URI,浏览器会自动定向到新的URI,今后任何新的请求都应使用新的URI代替 | *** |
302 | Found | 临时移动。与301类似,请求资源只是被临时移动,客户端应继续使用原URI | ** |
303 | See Other | 查看其它地址。与301类似,使用GET和POST请求查看 | * |
304 | Not Modified | 未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 | *** |
306 | Unused | 已经废弃的HTTP状态码 | - |
307 | Temporary Redirect | 临时重定向。与302类似,使用GET请求重定向 | ** |
400 | Bad Request | 客户端请求的语法错误,服务器无法理解 | *** |
401 | Unauthorized | 请求需要用户的身份认证 | *** |
402 | Payment Required | 保留,将来使用 | * |
403 | Forbidden | 服务器理解请求客户端的请求,但是拒绝执行此请求 | *** |
404 | Not Found | 无法找到所请求的 URL | *** |
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 | 请求实体过大 | *** |
414 | Request-URI Too Large | 请求的URI过长 | ** |
415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 | * |
416 | Requested range not satisfiable | 客户端请求的范围无效 | - |
417 | Exceptation Failed | 服务器无法满足Except的请求头信息 | |
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报文
HTTP 报文是由简单字符串组成,HTTP 报文都是纯文本,不是二进制代码,可以很方便地对其进行读写
HTTP 报文组成部分:
- 起始行:报文的第一行就是起始行,在请求报文中用来说明要做些什么,在响应报文中说明出现了什么情况
- 首部字段:起始行后面有零个或多个首部字段。每个首部字段都包含一个名字和一个值
- 主体:空行之后就是可选的报文主体了,其中包含了所有类型的数据
HTTP请求方法
HTTP1.0 定义了三种请求方法: GET, POST 和 HEAD方法
HTTP1.1 新增了六种请求方法:OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法
方法 | 描述 |
---|---|
GET | 请求指定的页面信息,并返回实体主体 |
HEAD | 类似于 GET 请求,只不过返回的响应中没有具体的内容,用于获取报头 |
POST | 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改 |
PUT | 从客户端向服务器传送的数据取代指定的文档的内容 |
DELETE | 请求服务器删除指定的页面 |
CONNECT | HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器 |
OPTIONS | 允许客户端查看服务器的性能 |
TRACE | 回显服务器收到的请求,主要用于测试或诊断 |
PATCH | 是对 PUT 方法的补充,用来对已知资源进行局部更 |
HTTP1.0与HTTP1.1的区别
- 缓存处理,在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since,If-Match,If-None-Match等更多可供选择的缓存头来控制缓存策略。
- 带宽优化及网络连接的使用,HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。
- 错误通知的管理,在HTTP1.1中新增了24个错误状态响应码,如==409(Conflict)==表示请求的资源与资源的当前状态发生冲突;==410(Gone)==表示服务器上的某个资源被永久性的删除。
- Host头处理,在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误 (400 Bad Request)。
- 长连接,HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,在HTTP1.1中默认开启Connection: keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
HTTP2.0和HTTP1.X相比的新特性
- 新的二进制格式(Binary Format),HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷,文本的表现形式有多样性,要做到健壮性考虑的场景必然很多,二进制则不同,只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式,实现方便且健壮。
- 多路复用(MultiPlexing),即连接共享,即每一个request都是是用作连接共享机制的。一个request对应一个id,这样一个连接上可以有多个request,每个连接的request可以随机的混杂在一起,接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
- header压缩,如上文中所言,对前面提到过HTTP1.x的header带有大量信息,而且每次都要重复发送,HTTP2.0使用encoder来减少需要传输的header大小,通讯双方各自cache一份header fields表,既避免了重复header的传输,又减小了需要传输的大小。
- 服务端推送(server push),例如我的网页有一个sytle.css的请求,在客户端收到sytle.css数据的同时,服务端会将sytle.js的文件推送给客户端,当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到,不用再发请求了。
HTTP与HTTPS的区别
- HTTP是超文本传输协议,信息明文传输,HTTPS是具有安全性的SSL加密传输协议;
- HTTPS协议需要ca申请证书,一般免费证书较少, 因而需要一定的费用;
- HTTP与HTTPS使用的是完全不同的连接方式, 使用的端口也不同,HTTP默认80,HTTPS默认443;
- HTTP连接时无状态的,HTTPS是由SSL加HTTP协议构建的可进行加密传输、身份认证的网络协议,安全性高于HTTP协议。
WebSocket
WebSocket是HTML5新增的协议,它的目的是在浏览器和服务器之间建立一个不受限的双向通信的通道,比如说,服务器可以在任意时刻发送消息给浏览器。
主要特点:
- 推送功能:支持由服务器向客户端推送数据的推送功能
- 减少通信量:只要建立起 WebSocket 连接,就希望一直保持连接状态
优点:
- 节约带宽。不停地轮询服务端数据这种方式,使用的是http协议,head信息很大,有效数据占比低, 而使用WebSocket方式,头信息很小,有效数据占比高。
- 无浪费。 轮询方式有可能轮询10次,才碰到服务端数据更新,那么前9次都白轮询了,因为没有拿到变化的数据。 而WebSocket是由服务器主动回发,来的都是新数据。
- 实时性,考虑到服务器压力,使用轮询方式不可能很短的时间间隔,否则服务器压力太多,所以轮询时间间隔都比较长,好几秒,设置十几秒。 而WebSocket是由服务器主动推送过来,实时性是最高的。
缺点
- 对开发者要求高了许多,对前端开发者,往往要具备数据驱动使用javascript的能力,且需要维持住ws连接(否则消息无法推送);对后端开发者而言,难度增大了很多,一是长连接需要后端处理业务的代码更稳定(不要随便把进程和框架都crash掉);
- 推送消息相对复杂一些;
- 成熟的http生态下有大量的组件可以复用,websocket则太新了一点。
相关考点:
建立TCP连接时,为什么需要三次握手,而不是二次握手?
防止已失效的连接请求报文段突然又传送给TCP服务器,避免产生错误,经过三次握手之后,通信双方的全双工链路,无论是收还是发,都经过了确认,这是才能证明通信双方的链路是可靠的。
TIME_WAIT是什么?为什么必须等待2MLS?
TIME_WAIT是TCP的一种状态,等待2MLS可以保证客户端最后一个ACK报文段能够到达服务器,如果未到达,服务器将会重复第三次挥手,重传连接释放报文段,以确保客户端和服务器都可以正常进入CLOSED(关闭)状态。
TCP粘包/拆包现象,以及解决办法。
-
造成的原因:
- 客户端要发送的数据大于TCP发送缓冲区剩余空间大小,将发生拆包;
- 待发送数据大于MSS(最大报文长度),TCP在传输前将进行拆包;
- 要发送的数据小于发送缓冲区的大小,连续发送数据时,由于tcp协议的nagle算法,TCP会将多次写入缓冲区的数据一次发送出去,将会发生粘包;
- 当发送内容较大时,由于服务器端的recv(buffer_size)方法中的buffer_size较小,接收数据端(服务器)的应用程序不能一次性读取接收缓冲区的数据,下一次请求到达时,依然接收的是上一次请求未接收完的数据,发生粘包。
-
解决办法:
- 发送端给每个数据包添加包首部,首部至少应包含数据包的长度,接收端接收到数据后,读取包首部长度字段,获取包长度;
- 发送端将每个数据包封装成固定长度(不足长度可以补0填充),接收端每次从接收缓冲区读取固定长度,即可拆分每个数据包;
- 在数据包之间设置边界(如添加特殊符号等),接收端通过此边界将不同的数据包分开。
TCP和UDP的区别,分别适用于什么场景?
对比项 | TCP | UDP |
---|---|---|
连接性 | 面向连接 | 无连接 |
可靠性 | 可靠,可靠交付 | 不可靠,尽最大努力交付 |
报文 | 面向字节流,流模式 | 面向报文,数据报文模式 |
双工性 | 全双工通信 | 一对一、一对多、多对一、多对多通信 |
流量控制 | 有(滑动窗口) | 无 |
拥塞控制 | 有(慢开始、拥塞避免、快重传、快恢复) | 无 |
传输速度 | 慢 | 快 |
资源开销 | 较多 | 较小 |
首部长度 | 20字节(160位) | 8字节(64位) |
传输数据顺序 | 保证 | 不保证 |
协议 | 应用场景说明 | 具体应用场景 |
---|---|---|
TCP | 对网络通信质量有要求,要求传输可靠性高,且传输的数据量较大 | HTTP、HTTPS、FTP等传输文件的协议,POP、SMTP等邮件传输的协议,如浏览器用的HTTP、FlashFXP用的FTP 、Outlook用的POP、SMTP、Putty用的Telnet、SSH、QQ文件传输等等 |
UDP | 对网络通信要求不高,响应速度要求高,拥有大量客户端(Client) | QQ语音、QQ视频、TFTP等等 |
GET和POST请求方式的区别
- 1.GET后退按钮/刷新无害,POST数据会被重新提交
- 2.GET书签可收藏,POST书签不可收藏
- 3.GET可以被浏览器缓存,POST不可以被缓存
- 4.GET历史参数保留在浏览器历史中,POST参数不会保留在浏览器历史中
- 5.GET请求编码类型application/x-www-form-urlencoded, POST请求编码类型application/x-www-form-urlencoded或multipart/form-data,为二进制数据使用多重编码
- 6.GET对数据长度有限制,发送数据时,GET请求向URL添加数据,URL长度是受限制的(最大长度2048个字符),POST理论上无限制
- 7.GET只允许ASCII码字符,POST无限制,支持二进制数据
- 8.与POST相比,GET安全性较差,因为所发送的数据是 URL 的一部分,POST 比 GET 更安全,因为参数不会被保存在浏览器历史或 web 服务器日志中
- 9.GET请求数据显示在URL上,对所有人可见,POST请求的数据不会显示在URL上
IPv6 与 IPv4 相比有哪些改进?
- 更大的地址空间
- 扩展的地址层次结构
- 灵活的首部格式
- 改进的选项
- 允许协议继续扩充
- 支持资源的预分配
什么是长连接?
长连接,指在一个连接上可以连续发送多个数据包,在连接保持期间,如果没有数据包发送,需要双方发链路检测包