设计数据链路层的原因

1、在原始的物理线路上传输数据信号是有差错的。

2、设计数据链路层的主要目的就是在原始的、有差错的物理传输线路的基础上，采取差错检测、差错控制与流量控制等方法，将有差错的物理线路改进成逻辑上无差错的数据链路，向网络层提供高质量的服务。

3、从网络参考模型的角度看，物理层之上的各层都有改善数据传输质量的责任，数据链路层是最重要的一层。

数据链路层的最基本的功能是向该层用户提供透明的和可靠的数据传送基本服务。透明性是指该层上传输的数据的内容、格式及编码没有限制，也没有必要解释信息结构的意义；可靠的传输使用户免去对丢失信息、干扰信息及顺序不正确等的担心。在物理层中这些情况都可能发生，在数据链路层中必须用纠错码来检错与纠错。数据链路层是对物理层传输原始比特流的功能的加强，将物理层提供的可能出错的物理连接改造成为逻辑上无差错的数据链路，使之对网络层表现为一无差错的线路。如果您想用尽量少的词来记住数据链路层，那就是：“帧和介质访问控制”。 为了使传输中发生差错后只将有错的有限数据进行重发，数据链路层将比特流组合成以帧为单位传送。每个帧除了要传送的数据外，还包括校验码，以使接收方能发现传输中的差错。帧的组织结构必须设计成使接收方能够 明确地从物理层收到的比特流中对其进行识别，也即能从比特流中区分出帧的起始与终止，这就是帧同步要解决的问题。由于网络传输中很难保证计时的正确和一致，所以不可采用依靠时间间隔关系来确定一帧的起始与终止的方法。

（1）字节计数法：这是一种以一个特殊字符表示一帧的起始并以一个专门字段来标明帧内字节数的帧同步方法。接收方可以通过对该特殊字符的识别从比特流中区分出帧的起始并从专门字段中获知该帧中随后跟随的数据字节数，从而可确定出帧的终止位置。面向字节计数的同步规程的典型代表是DEC公司的数字数据通信报文协议DDCMP（Digital Data Communications Message Protocol）。DDCMP采用的帧格式如图3-1。

控制字符SOH标志数据帧的起始。实际传输中，SOH前还要以两个或更多个同步字符来确定一帧的起始，有时也允许本帧的头紧接着上帧的尾，此时两帧间就不必再加同步字符。 count字段共有14位，用以指示帧中数据段中数据的字节数，14位二进制数的最大值为2-1=16383，所以数据最大长度为8×16383=131064。DDCMP协议就是靠这个字节计数来确定帧的终止位置的。DDCMP帧格式中的ACK、SEG、ADDR及FLAG中的第2位，CRC1、CRC2分别对标题部分和数据部分进行双重校验，强调标题部分单独校验的原因是，一旦标题部分中的CONUT字段出错，即失却了帧边界划分的依据，将造成灾难性的后果。由于采用字符计数方法来确定帧的终止边界不会引起数据及其它信息的混淆，因而不必采用任何措施便可实现数据的透明性（即任何数据均可不受限制地传输）。

（2）使用字符填充的首尾定界符法：该法用一些特定的字符来定界一帧的起始与终止，为了不使数据信息位中出现的与特定字符相同的字符被误判为帧的首尾定界符，可以在这种数据字符前填充一个转义控制字符（DLE）以示区别，从而达到数据的透明性。但这种方法使用起来比较麻烦，而且所用的特定字符过份依赖于所采用的字符编码集，兼容性比较差。

（3）使用比特填充的首尾标志法：该法以一组特定的比特模式（如01111110）来标志一帧的起始与终止。本章稍后要详细介绍的HDLC规程即采用该法。为了不使信息位中出现的与特定比特模式相似的比特串被误判为帧的首尾标志，可以采用比特填充的方法。比如，采用特定模式01111110，则对信息位中的任何连续出现的五个“1”，发送方自动在其后插入一个“0”，而接收则做该过程的逆操作，即每接收到连续五个“1”，则自动删去其后所跟的“0”，以此恢复原始信息，实现数据传输的透明性。比特填充很容易由硬件来实现，性能优于字符填充方法。

（4）违法编码法：该法在物理层采用特定的比特编码方法时采用。例如，一种被称作曼彻斯特编码的方法，是将数据比特“1”编码成“高－低”电平对，而将数据比特“0”编码成“低－高”电平对。而“高－高”电平对和“低－低”电平对在数据比特中是违法的。可以借用这些违法编码序列来定界帧的起始与终止。局域网IEEE 802标准中就采用了这种方法。违法编码法不需要任何填充技术，便能实现数据的透明性，但它只适用于采用冗余编码的特殊编码环境。由于字节计数法中COUNT字段的脆弱性以及字符填充法实现上的复杂性和不兼容性，较普遍使用的帧同步法是比特填充和违法编码法。 为了提高信道的有效利用率。如前节所述采用了发送方不等待确认帧返回就连续

发送若干帧的方案，这样的发送过程就象一条连续的流水线，故又称为管道(pipelining)技术。由于允许连续发送多个未被确认折帧，帧号就采用多位二进制数才能加以区分。因为凡被发送出去但沿尚未被确认的帧都可能出错或丢失而要求重发，因而这些帧都要保留下来。这就要求发送方有较大的发送缓冲区保留可能要求重发的未被确认的帧。但是缓冲区容量总是有限的，如果接收方不能以发送方的发送速率处理收到的帧，则还是可能用完缓冲容量而暂时过载。为此，可引入类似于空闲RQ方案的调整措施，其本质是在收到一确定帧之前，对发送方可发送的帧的数目加以限制，这是由发送方调整保留在重发表中的待确认帧的数目来实现的。如果接收方来不及对收到的帧进行处理，则接收方停发确认信息，此时送方的重发表增长，当达到重发表限度时，就不再发送新帧，直至再次收到确认信息为止。 为了实现此方案，存放未确认帧的重发表中应设置未确认帧数目的最大限度，这一限度被称为链路的发送窗口。显然，如果窗口设置为1，即发送方缓冲能力公为一个帧，则传输控制方案就回到了空闲RQ方案，此时传输效率很低，故窗口限度应选为使接收方尽量能处理或接受收到的所有帧。当然选择时还必须考虑诸如帧的最大长度、可使用的缓冲存容量以及传输的比特速率等因素。重发表是一个连续序号的列表，对应发送方已发送但尚未确认的那些帧。这些帧的序号有一个最大值即发送窗口的限度。所谓发送窗口就是指示发送方已发送但尚未确认的帧序号队列的界，其上、下界分别称为发送窗口的上、下沿，上、下沿的间距称为窗口尺寸。接收方类似地有接收窗口，它指示允许接收的帧的序号。接收窗口的上、下界也是随时间滑动的。

发送方每次发送一帧后，待确认帧的数目便增1；同样，发送方每收到一个确认信息后，待确认帧的数目便减1。当重发计数值，即待确认帧的数目等于发送窗口时，便停止发送新的帧。一般帧号只取有限位二进制数，到一定时间后就又反复循环，若帧号配3位二进制，则帧号在0～7间循环。如果发送窗口限度取值为2，则发送过程如图3-4所示。图中发送方阴影表示发送窗口，接收方阴影则相应可视作接收窗口。当传送过程进行时，窗口位置一直在滑动，所以也称为滑动窗口（Slidding Window)，或简称为滑窗。

图3-4中滑动窗口的状态变化过程可叙述如下（假设发送窗口为2，接收窗口为1）。

初始态，发送方没有帧发出，发送窗口前后沿相等。接收窗口限度为1，它允许接收0号帧。

发送方已发送0号帧，此时发作口打开（即前沿加1），窗口对准0号，表示已发出但尚未收到确认返回信息。接收窗口状态同前，指示允许接收0帧。

发送方在未收到0帧的确认返回信息前，继续发送1号帧。发送窗口状态不变。

接收方已收到0帧，窗口滑动一格，表示准备接收1号帧。发送窗口状态不变。

发送方已收到0号帧的确认返回信息，发送窗口后沿加1，表示从重发表中删除0号帧，接收窗口状态不变。

发送方继续发送2帧，发送窗口前沿加1，表示2号帧也纳入待确认之列。接收

窗口状态仍不变。

接收方已收到1号帧，接收窗口滑动一格，表示准备接收2号帧。发送窗口状态不变。

发送方收到接收方发来的1号帧收毕的确认信息，发送窗口后沿加1，表示从重发表中删除最早进入的1号帧。接收窗口状态不变。 一般说来，凡是在一定范围内到达的帧，那怕不按顺序，接收方也要接收下来。若把这个范围看成是接收窗口的话，则接收窗口的大小应该是大于1的，而Go-back-N正是接收窗口等于1的一个特例。选择重发也可以看作是一种滑动窗口协议，只不过其发送窗口和接收窗口都大于1。若从滑动窗口的观点来统一看待空闲RQ、Go-back-N及选择重发三种协议，它们的差别公在于各自窗口的大小不同而已：

空闲RQ：发送窗口=1，接收窗口=1

Go-back-N：发送窗口>1，接收窗口=1

选择重发：发送窗口>1，接收窗口>1

若帧序号采用3位二进制编码，则最大序号为SMAX=2^3－1=7。对于有序接收方式，发送窗口最大尺寸选为SMAX；对于无笆接收方式，发送窗口最大尺寸至多是序号范围的一半。管理超时控制的计时器应等于发送缓冲器数，而不是序号空间的大小。实际上，每一个缓冲器应对应一个计时器，当计时器超时时，该对应缓冲器的内容重发。按收方必须设置的缓冲器数应该等于接收窗口尺寸，而不是序号空间的大小。

第一层：应用层，定义了用于在网络中进行通信和传输数据的接口；（Http协议位于该层）

第二层：表示层，定义不同系统中数据的传输格式，编码和解码规范等；

第三层：会话层，管理用户的会话，控制用户间逻辑连接的建立和中断；

第四层：传输层，管理着网络中端到端的数据传输；（Tcp协议位于该层）

第五层：网络层，定义网络设备间如何传输数据；（IP位于该层）

第六层：链路层，将上面的网络层的数据包封装成数据帧，便于物理层传输；

第七层：物理层，这一层主要就是传输这些二进制数据。

建立起一个 TCP 连接需要经过“ 三次握手 ”：

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求。

SYN攻击就是利用三次握手的第二次握手时进行的，这时候服务器处于SYN_RECV状态，等待客户端进行确认ACK，SYN会伪造不存在的源IP，就会有大量的链接处于等待或重试发送SYN+ACK包，导致该阶段队列持续增长，进而导致后续正常请求被丢弃。

HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”。

要保持客户端程序的在线状态，需要不断地向服务器发起连接请求，通常情况下即使不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。

通常情况下Socket连接就是TCP连接，因此Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网络应用中，客户端到服务器之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。

而HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。

很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器就可以直接将数据传送给客户端；若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求，不仅可以保持在线，同时也是在“询问”服务器是否有新的数据，如果有就将数据传给客户端。

相关视频推荐

看完《tcp/ip详解》不能coding的，一次课开启设计tcp/ip协议栈

深入聊聊websocket协议，tcp分包与粘包解决方案

学习地址：C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂

需要C/C++ Linux服务器架构师学习资料加qun 812855908 获取（资料包括 C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg 等），免费分享

创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。

socket则是对TCP/IP协议的封装和应用（程序员层面上）。也可以说，TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。

关于TCP/IP和HTTP协议的关系，网络有一段比较容易理解的介绍：

平时说的最多的socket是什么呢，实际上socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，才能使用TCP/IP协议。

实际上，Socket跟TCP/IP协议没有必然的联系。Socket编程接口在设计的时候，就希望也能适应其他的网络协议。所以说，Socket的出现 只是使得程序员更方便地使用TCP/IP协议栈而已，是对TCP/IP协议的抽象，从而形成了一些最基本的函数接口，比如create、 listen、connect、accept、send、read和write等等。

实际上，传输层 TCP 是基于网络层 IP 协议的，而应用层 HTTP 协议又是基于传输层 TCP 协议的，而 Socket 本身不算是协议，就像上面所说，它只是提供了一个针对 TCP 或者 UDP 编程的接口。

总结：

Socket 其实并不是一个协议，而是为了方便使用 TCP/UDP 而抽象出来的一层，是位于应用层和传输控制层之间的一组接口。

当两台主机通信时，必须通过Socket连接，Socket则利用TCP/IP协议建立TCP连接。TCP连接则更依靠于底层的IP协议，IP协议的连接则依赖于链路层等更低层次。

WebSocket就像HTTP一样，是一个典型的应用层协议。

总结：

WebSocket是HTML5规范提出的一种协议。HTML5 Web Sockets规范定义了Web Sockets API，支持页面使用Web Socket协议与远程主机进行全双工的通信。它引入了WebSocket接口并且定义了一个全双工的通信通道，通过一个单一的套接字在Web上进行操作。

HTML5 Web Sockets以最小的开销高效地提供了Web连接。相较于经常需要使用推送实时数据到客户端甚至通过维护两个HTTP连接来模拟全双工连接的旧的轮询或长轮询（Comet）来说，这就极大的减少了不必要的网络流量与延迟。

相同点：

不同点：

联系：

WebSocket连接的过程：

总结：