主要参考计算机网络(第7版)谢希仁 编著


TCP通讯特点:

  • TCP是面向连接的运输层协议。 这就是说, 应用程序在使用TCP协议之前, 必须先建立TCP连接。 在传送数据完毕后, 必须释放已经建立的TCP连接。 也就是说, 应用进程之间的通信好像在 “ 打电话”:通话前要先拨号建立连接, 通话结束后要挂机释放连接。
  • 每条TCP连接只能有两个端点(endpoint), 每一条TCP连接只能是点对点的(一 对一)
  • TCP提供可靠交付的服务。 通过TCP连接传送的数据, 无差错、 不丢失、 不重复,并且按序到达。
  • TCP 提供全双工通信。 TCP允许通信双方的应用进程在任何时候都能发送数据。 TCP连接的两端都设有发送缓存和接收缓存, 用来临时存放双向通信的数据。 在发送时,应用程序在把数据传送给TCP的缓存后, 就可以做自己的事, 而TCP在合适的时候把数据发送出去。 在接收时, TCP把收到的数据放入缓存, 上层的应用进程在合适的时候读取缓存中的数据。
  • 面向字节流。 TCP中的 “ 流” (stream)指的是流入到进程或从进程流出的字节序列。 面向字节流” 的含义是: 虽然应用程序和TCP的交互是一次 一个数据块(大小不等), 但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。 TCP并不知道所传送的宇节流的含义。 TCP不保证接收方所收到的数据块和发送方所发出的数据块具有对应大小的关系(例如, 发送方应用程序交给发送方的TCP共10个数据块, 但接收方的TCP可能只用了4个数据块就把收到的字节流交付上层的应用程序)。但接收方收到的字节流必须和发送方发出的字节流完全 一样。 当然, 接收方的应用程序必须有能力识别收到的宇节流, 把它还原成有意义的应用层数据。

图中的TCP 连接是一条虚连接(也就是逻辑连接〉, 而不是一条真正的物理连接。 TCP报文段先要传送到IP层, 加上IP首部后, 再传送到数据链路层。 再加上数据链路层的首部和尾部后, 才离开主机发送到物理链路。

TCP和UDP在发送报文时采取的方式不同:

TCP和UDP在发送报文时所采用的方式完全不同。

TCP并不关心应用进程一次把多长的报文发送到TCP的缓存中, 而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节(UDP发送的报文长度是应用进程给出的)。

如果应用进程传送到 TCP缓存的数据块太长,TCP 就可以把它划分短一些再传送。 如果应用进一程次只发来一个字节, TCP也可以等待积累有足够多的字节后 再构成报文段发送出去。

TCP的连接:

TCP把连接作为最基本的抽象。

TCP的许多特性都与TCP是面向连接的这个基本特性有关。 因此我们对TCP连接需要有更清楚的了解。
前面已经讲过, 每一条TCP连接有两个端点。 那么,TCP连接的端点是什么呢?不是主机, 不是主机的 IP 地址, 不是应用进程,也不是运输层的协议端口。

TCP连接的端点叫做套接字(socket)或插口。

根据RC 793的定义: 端口号拼接到( concatenated with) IP地址即构成了套接字

因此, 套接字的表示方法是在点分十进制的 IP 地址后面写上端口号, 中间用冒号或逗号隔开。

例如, 若IP地址是192.3.4.5而端口号是 80, 那么得到的套接字就是 ( 192.3.4.5: 80)。

                       每一条TCP连接唯-地被通信两端的两个端点(即两个套接宇〉所确定。

这里IP1和 IP2分别是两个端点主机的E地址,而po矶和port2分别是两个端点主机中的端口号。

TCP连接的两个套接字就是socket 1和socket 2。

TCP 连接就是由协议软件所提供的一种抽象。 虽然有时为了方便, 我们也可以说, 在一个应用进程和另一个应用进程之间建立了一条TCP连接, 但一定要记住,TCP连接的端点是个很抽象的套接字, 即(Ip地址:端口号)。也还应记住, 同一个地址可以有多个不同的TCP连接,而同一个端口号也可以出现在多个不同的TCP连接中。

TCP报文段:

TCP虽然是面向字节流的,但TCP传送的数据单元却是报文段。一个TCP报文段分为 首部和数据两部分,而TCP的全部功能都体现在它首部中各宇段的作用。因此,只有弄清TCP首部各字段的作用才能掌握TCP的工作原理。

下面讨论TCP报文段的首部格式
TCP报文段首部的前20个字节是固定的,后面有 4n 字节是根据需要而增加的选项Cn是整数)。 因此TCP首部的最小长度是20字节。

TCP的运输连接管理:

TCP是面向连接的协议。 运输连接是用来传送TCP报文的。 TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。

因此, 运输连接就有三个阶段, 即:

  1. 连接建立
  2. 数据传送
  3. 连接释放

运输连接的管理就是使运输连接的建立和释放都能正常地进行。

在TCP连接建立过程中要解决以下三个问题:

  1. 要使每一方能够确知对方的存在。
  2. 要允许双方协商一些参数(如最大窗口值、 是否使用窗口扩大选项和时间戳选项以及服务质量等)
  3. 能够对运输实体资源(如缓存大小,连接表中的项目等)进行分配。

TCP连接的建立采用客户服务器方式。 主动发起连接建立的应用进程叫做客户(client),而被动等待连接建立的应用进程叫服务器(server)

TCP的连接建立

TCP建立连接的过程叫做握手, 握手需要在客户和服务器之间交换三个TCP报文段。

下图画出了三报文握手(three way handshake)建立TCP连接的过程。

假定主机A运行的是TCP客户程序, 而B运行TCP服务器程序。 最初两端的TCP进程都处于 CLOSED (关闭)状态。

图中在主机下面的方框分别是TCP进程所处的状态。 请注意, 在本例中, A主动打开连接, 而B被动打开连接。

开始,B 的 TCP服务器进程先创建传输控制块TCB,准备接受客户进程的连接请求。 然后服务器进程就处于 LISTENC(收听)状态等待客户的连接请求。 如有,即作出响应。

A的TCP客户进程也是首先创建传输控制模块TCB。 然后 ,在打算建立TCP连接时,向B(服务器)发出连接请求报文段, 这时首部中的同步位SYN = 1,同时选择一个初始序号 seq =y。TCP规定, SYN报文段(即 SYN= 1 的报文段)不能携带数据, 但要消耗掉一个序号。 这时, TCP客户进程进入SYN-SENT (同步已发送)状态。

B收到连接请求报文段后, 如同意建立连接, 则向A发送确认。 在确认报文段中应把SYN位和ACK位都置1, 确认号是ack=x+l,同时也为自己选择一个初始序号seq = y。 请注意, 这个报文段也不能携带数据, 但同样要消耗掉一个序号。 这时 TCP服务器进程进入SYN-RCVD (同步收到)状态。

TCP客户进程收到B的确认后, 还要向B(服务器)给出确认。 确认报文段的 ACK置1,确认号ack = y + 1, 而自己的序号seq = x+l。 TCP的标准规定, ACK报文段可以携带数据。 但如果不携带数据则不消耗序号, 在这种情况下, 下一个数据报文段的序号仍是seq = x+l。这时,TCP连接己经建立, A(客户端)进入ESTABLISHED (己建立连接)状态。
B(服务器)收到A(客户端)的确认后, 也进入ESTABLISHED状态。

上面给出的连接建立过程叫做三报文握手。 请注意, 在图中B(服务器)发送给A(客户端)的报文段, 也可拆成两个报文段。 可以先发送一个确认报文段(ACK= 1, ack = x + 1), 然后再发送一个同步报文段(SYN = 1, seq = y)。这样的过程就变成了四报文握手,但是效果一样。

第三次握手的原因:

为什么A(客户端)最后还要发送一次确认呢?这主要是为了防止己失效的连接请求报文段突然又传送到了B(服务器), 因而产生错误。
所谓 “己失效的连接请求报文段” 是这样产生的。 考虑一种正常情况, A(客户端)发出连接请求, 但因连接请求报文丢失而未收到确认。 于是A(客户端)再重传一次连接请求。 后来收到了确认, 建立了连接。 数据传输完毕后, 就释放了连接。 A(客户端)共发送了两个连接请求报文段, 其中第一个丢失,第二个到达了B(服务器), 没有 “己失效的连接请求报文段”。

现假定出现一种异常情况, 即A(客户端)发出的第一个连接请求报文段并没有丢失, 而是在某些网络结点长时间滞留了, 以致延误到连接释放以后的某个时间才到达B(服务器)。 本来这是一个早己失效的报文段。 但B(服务器)收到此失效的连接请求报文段后, 就误认为是A(客户端)又发出一次新的连接请求。 于是就向A(客户端)发出确认报文段, 同意建立连接。 假定不采用报文握手, 那么只要B(服务器) 发出确认, 新的连接就建立了。

由于现在A(客户端)并没有发出建立连接的请求, 因此不会理睬B(服务器)的确认, 也不会向B(服务器)发送数据。 但B(服务器)却以为新的运输连接已经建立了, 并一直等待A发来数据。 B(服务器)的许多资源就这样白白浪费了。

采用三报文握手的办法, 可以防止上述现象的发生。 例如在刚才的异常情况下, A(客户端)不会向B(服务器)的确认发出确认。 B(服务器)由于收不到确认, 就知道A(客户端)并没有要求建立连接。

TCP的连接释放

TCP连接释放过程比较复杂, 我们仍结合双方状态的改变来阐明连接释放的过程。
数据传输结束后, 通信的双方都可释放连接。 现在A和B都处于ESTABLISHED状态

A的应用进程先向其TCP发出连接释放报文段, 并停止再发送数据, 主动关闭TCP连接。 A把连接释放报文段首部的终止控制位FIN置l, 其序号seq= u, 它等于前面已传送过的数据的最后一个字节的序号1。 这时 A进入FIN-WAI下1 (终止等待1) 状态, 等待B的确认。 请注意, TCP规定, FIN报文段即使不携带数据, 它也消耗掉一个序号。

B收到连接释放报文段后即发出确认, 确认号是ack= u + 1, 而这个报文段自己的序号是v, 等于 B 前面己传送过的数据的最后 个字节的序号加1。 然后 B就进入CLOSE­WAIT (关闭等待) 状态。 TCP服务器进程这时应通知高层应用进程, 因而从A到B这个方向的连接就 释放了, 这时的 TCP连接处于半关闭(half-close)状态, 即A已经没有数据要发送了, 但B若发送数据, A仍要接收。 也就是说, 从B到A这个方向的连接并未关闭, 这一个状态可能会持续 段时间。A收到来自B的确认后, 就进入FIN-WAIT-2 (终止等待2)状态, 等待B发出的连接释放报文段。

若B己经没有要向A发送的数据, 其应用进程就通知TCP释放连接。 这时B发出的连一接释放报文段必须使FIN= 1。 现假定B的序号为w (在半关闭状态B可能又发送了 些数据)。 B还必须重复上次已发送过的确认号ack = u + 1。这时B就进入LAS下ACK C最后确认)状态, 等待A的确认。

A在收到B的连接释放报文段后, 必须对此发出确认。 在确认报文段中把ACK置1,确认号ack = w + 1, 而自己的序号是seq = u+l (根据TCP标准, 前面发送过的FIN报文段要消耗一个序号)。 然后进入到TIME-WAIT(时间等待 ) 状态。 请注意, 现在 TCP 连接还没有释放掉。 必须经过时间等待计时器(TIME-WAITtimer)设置的时间2MSL 后, A才进 入到 CLOSED状态。 时间MSL叫做最长报文段寿命(Maximum Segment Lifetime),盯C 793 建议设为2分钟。 但这完全是从工程上来考虑的, 对于现在的网络, MSL =2分钟可能太长 了一些。 因此TCP允许不同的实现可根据具体情况使用更小的MSL值。 因此, 从A进入
到TIME-WAIT状态后,要经过4分钟才能进入到 CLOSED状态, 才能开始建立下一个新的连接。 当 A撤销相应的传输控制块TCB后, 就结束了这次的TCP连接。

为什么 A在TIME-WAIT状态必须等待2MSL的时间呢?这有两个理由。
第一,为了保证A发送的 最后一个ACK报文段能够到达B。 这个ACK报文段有可能丢失, 因而使处在LAS下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状态。
第二, 防止上一节提到的 “己失效的连接请求报文段” 出现在本连接中。 A在发送完最 后一个 ACK报文段后, 再经过时间2MSL, 就可以使本连接持续的时间内所产生的所有报 文段都从网络中消失。 这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。
B只要收到了 A发出的确认, 就进入CLOSED状态。 同样, B在撤销相应的传输控制块TCB后, 就结束了这次的TCP连接。 我们注意 到, B结束TCP连接的时间要比A早一些。

上述的TCP连接释放过程是四报文握手。


Qt使用WIFI进行TCP通讯


补充:计算机网络重要知识点概述

计算机网络体系结构

在计算机网络的基本概念中, 分层次的体系结构是最基本的。 计算机网络体系结构的抽象概念较多, 在学习时要多思考。 这些概念对后面的学习很有帮助。

计算机网络体系结构的形成

计算机网络是个非常复杂的系统。 为了说明这一点, 可以设想一种最简单的情况:

连接在网络上的两台计算机要互相传送文件。

显然, 在这两台计算机之间必须有一条传送数据的通路。 但这还远远不够。 至少还有以下几项工作需要去完成:

(1)发起通信的计算机必须将数据通信的通路进行激活(activate)。 所谓 “ 激活 ” 就是要发出一些信令, 保证要传送的计算机数据能在这条通路上正确发送和接收。

(2)要告诉网络如何识别接收数据的计算机

(3)发起通信的计算机必须查明对方计算机是否己开机, 并且与网络连接正常。

(4)发起通信的计算机中的应用程序必须弄清楚, 在对方计算机中的文件管理程序是否己做好接收文件和存储文件的准备工作。

(5)若计算机的文件格式不兼容, 则至少其中一台计算机应完成格式转换功能

(6)对出现的各种差错和意外事故, 如数据传送错误、 重复或丢失, 网络中某个结点交换机出现故障等, 应当有可靠的措施保证对方计算机最终能够收到正确的文件。

还可以列举出一些要做的其他工作。 由此可见, 相互通信的两个计算机系统必须高度协调工作才行, 而这种 “协调” 是相当复杂的。 为了设计这样复杂的计算机网络, 早在最初的 ARPANET设计时即提出了分层的方法。 “ 分层 ” 可将庞大而复杂的问题, 转化为若干较小的局部问题, 而这些较小的局部问题就比较易于研究和处理。

1974年, 美国的IBM 公司宣布了系统网络体系结构SNA (System Network Architec阳re)。这个著名的网络标准就是按照分层的方法制定的。 现在用 IBM大型机构建的专用网络仍在使用 SNA。不久后, 其他一些公司也相继推出自己公司的具有不同名称的体系结构。
不同的网络体系结构出现后, 使用同一个公司生产的各种设备都能够很容易地互连成网。 这种情况显然有利于一个公司垄断市场。 但由于网络体系结构的不同, 不同公司的设备很难互相连通。
然而, 全球经济的发展使得不同网络体系结构的用户迫切要求能够互相交换信息。 为了使不同体系结构的计算机网络都能互连, 国际标准化组织IS O于 1977年成立了专门机构研究该问题。 他们提出了一个试图使各种计算机在世界范围内互连成网的标准框架, 即著名的开放系统互连基本参考模型OSI忠M (Open Systems Interconnection Reference Model), 简称为 OSI。 “开放” 是指非独家垄断的。因此只要遵循 OSI 标准, 个系统就可以和位于世 界上任何地方的、 也遵循这同一标准的其他任何系统进行通信。 这一点很像世界范围的有线电话和邮政系统, 这两个系统都是开放系统。"系统” 是指在现实的系统中与互连有关的各部分(我们知道, 并不是一个系统中的所有部分都与互连有关。 OSI/RM把与互连无关的部分除外, 而仅仅考虑与互连有关的那些部分)。所以 OSI成M是个抽象的概念。 在1983年形 成了 开放系统互连 基本参考模型的正式文件, 即著名的 ISO 7498 国际标准, 也就是所谓的七层协议的体系结构。
OSI试图达到 一种理想境界, 即全球计算机网络 都遵循这个统一标准, 因而全球的计算机将能够很方便地进行互连和交换数据。 在20世纪80年代, 许多大公司甚至一些国家的政府机构纷纷表示支持OSI。当时看来似乎在不久的将来 全世界一定会按照OSI制定的标准来 构造自己的计算机网络。 然而到了20世纪90年代初期, 虽然整套的 OSI国际标准 都己经制定 出来 了, 但由于基于 TCP/IP 的互联网己抢先在全球相当大的范围成功地运行了, 而与此同时却几乎找不到有什么厂家生产 出符合 OSI 标准的商用产品。 因此人们得出这样的结 论: OSI只获得了一些理论研究的成果,但在市场化方面则事与愿连地失败 了。 现今规模最大的、覆盖全球的、基于TCP/IP的互联网并未使用 OSI标准。 OSI失败的原因可归纳为:

  1. OSI的专家们缺乏实际经验, 他们在完成OSI标准时缺乏商业驱动力:
  2. OSI的协议实现起来过分复杂, 而且运行效率很低:
  3. OSI标准的制定周期 太长, 因而使得按OSI标准生产的设备无法及时进入市场:
  4. OSI的层次划分不太合理, 有些 功能在多个层次中重复出现。

按照一般的概念, 网络技术和设备只有符合有关的国际标准才能大范围地获得工程上的应用。 但现在情况却反过来了。 得到最广泛应用的不是法律上的国际标准OSI, 而是非国际标准 TCP/IP。这样, TCP/IP 就常被称为是事实上的国际标准。 从这种意义上说, 能够占领市场的就是标准。 在过去制定标准的组织中往往 以专家、 学者为主。 但现在许多公司都纷纷加入各种标准化组织, 使得技术标准具有浓厚的商业气息。一个新标准的出现, 有时不定反映其技术水平是最先进的, 而是往往有着一定的市场背景。

协议与划分层次

在计算机网络中要做到有条不紊地交换数据, 就必须遵守一些事先约定好的规则。 这些规则明确规定了所交换的数据的格式以及有关的同步问题。 这里所说的同步不是狭义的(即同频或同频同相) 而是广义的, 即在一定的条件下应当发生什么事件(例如, 应当发送一个应答信息), 因而同步含有时序的意思。 这些为进行网络中的数据交换而建立的规则

  1. 语法, 即数据与控制信息的结构或格式:
  2. 语义, 即需要发出何种控制信息, 完成何种动作以及做出何种响应:
  3. 同步, 即事件实现顺序的详细说明。

由此可见, 网络协议是计算机网络不可缺少的组成部分。 实际上, 只要我们想让连接在网络上的另一台计算机做点什么事情(例如, 从网络上的某台主机下载文件), 我们都需要有协议。 但是当我们经常在自己的个人电脑上进行文件存盘操作时,就不需要任何网络协议, 除非这个用来存储文件的磁盘是网络上的某个文件服务器的磁盘。协议通常有两种不同的形式。一种是使用便于人来阅读和理解的文字描述。 另一种是使用让计算机能够理解的程序代码。 这两种不同形式的协议都必须能够对网络上的信息交换过程做出精确的解释。

ARPANET的研制经验表明, 对于非常复杂的计算机网络协议, 其结构应该是层次式的。 我们可以举个简单的例子来说明划分层次的概念。

现在假定我们在主机1和主机2之间通过一个通信网络传送文件。这是一项比较复杂的工作,因为需要做不少的工作。

我们可以将要做的工作划分为三类

第一类工作与传送文件直接有关。例如,发送端的文件传送应用程序应当确信接收端的文件管理程序已做好接受和存储文件的准备。如两台主机所用的文件格式不一样,则至少其中的一台主机应完成文件格式的转换。这两项工作可用一个文件传送模块来完成。这样,两台主机可将文件传送模块作为最高的一层。在这两个模块之间的虚线表示两台主机系统交换文件和一些有关文件交换的命令。

但是, 我们并不想让文件传送模块完成全部工作的细节, 这样会使文件传送模块过于复杂。 可以再设立一个通信服务模块, 用来保证文件和文件传送命令可靠地在两个系统之间交换。 也就是说, 让位于上面的文件传送模块利用下面的通信服务模块所提供的服务。 我们还可以看出, 如果将位于上面的文件传送模块换成电子邮件模块, 那么电子邮件模块同样可以利用在它下面的通信服务模块所提供的可靠通信的服务。同样道理, 我们再构造一个网络接入模块, 让这个模块负责做与网络接口细节有关的 工作, 并向上层提供服务, 使上面的通信服务模块能够完成可靠通信的任务。

计算机网络的各层及其协议的集合就是网络的体系结构(architecture)。 换种说法, 计算机网络的体系结构就是这个计算机网络及其构件所应完成的功能的精确定义。需要强调的是:这些功能究竟是用何种硬件或软件完成的, 则是一个遵循这种体系结构的实现(implementation)的问题。 体系结构的英文名词architecture的原意是建筑学或建筑的设计和风格。 它和一个具体的建筑物的概念很不相同。 例如,我们可以走进一个明代的建筑物中,但却不能走进一个明代的建筑风格之中。 同理,我们也不能把一个具体的计算机网络说成是一个抽象的网络体系结构。 总之,体系结构是抽象的,而实现则是具体的,是真正在运行的计算机砸件和软件。

OSI的七层协议体系结构的概念清楚, 理论也较完整, 但它既复杂又不实用。 TCP/IP体系结构则不同, 但它现在却得到了非常广泛的应用。 TCP/IP是一个四层的体系结构,它包含应用层、 运输层、 网际层和网络接口层(用网际层这个名字是强调这一层是为了解决不同网络的互连问题)。 不过从实质上讲, TCP/IP只有最上面的三 层, 因为最下面的网络接口层并没有什么具体内容。 因此在学习计算机网络的原理时往往采取 折中的办法, 即综合OSI和TCP/IP的优点,采用一种只有五层协议的体系结构,这样既简洁又能将概念阐述清楚。有时为了方便, 也可把最底下两层称为网络接口层。

现在结合互联网的情况, 自上而下地、 非常简要地介绍一下各层的主要功能。 实际 上, 只有认真学习完本书各章的协议后才能真正弄清各层的作用。

( 1)应用层(application layer) 

应用层是体系结构中的最高层。 应用层的任务是通过应用进程间的交互来完成特定网络应用。 应用层协议定义的是应用进程间通信和交互的规则。 这里的进程就是指主机中正在运行的程序。 对于不同的网络应用需要有不同的应用层协议。 在互联网中的应用层协议很多, 如域名系统DNS, 支持万维网应用的HTTP协议, 支持电子邮件的SMTP协议, 等等。我们把应用层交互的数据单元称为报文(message)。

(2)运输层(transport layer)

运输层的任务就是负责向两台主机中进程之间的通信提供通用的数据传输服务。 应用进程利用该服务传送应用层报文。 所谓 “通用的 ”,是指并不针对某个特定网络应用, 而是多种应用可以使用同一个运输层服务。 由于 一台主机可同时运行多个进程, 因此运输层有复 用和分用的功能。 复用就是多个应用层进程可同时使用下面运输层的服务, 分用和复用相反, 是运输层把收到的信息分别交付上面应用层中的相应进程。

•    传输控制协议TCP(Transmission Control Protocol)一一提供面向连接的、可靠的数据传输服务,其数据传输的单位是报文段(segment)。
•    用户数据报协议UDP (User Datagram Protocol)-提供无连接的、 尽最大努力 (best-effort)的数据传输服务(不保证数据传输的可靠性), 其数据传输的单位是用 户数据报。

(3)网络层(networklayer)

网络层负责为分组交换网上的不同主机提供通信服务。在发送数据时,网络层运输层产生的报文段或用户数据报封装成分组或包进行传送。 在TCP/IP体系中, 由于网络层使用IP协议, 因此分组也叫做IP数据报, 或简称为数据报。 本书把 “分组” 和 “数据报” 作 为同义词使用。
请注意: 不要将运输层的 “用户数据报UDP” 和网络层的 “IP数据报” 弄混。 此外,无论在哪一层传送的数据单元, 都可笼统地用 “分组” 来表示。
网络层的另一个任务就是要选择合适的路由, 使源主机运输层所传下来的分组, 能够通过网络中的路由器找到目的主机。
这里要强调指出, 网络层中的 “ 网络 ” 二字, 己不是我们通常谈到的具体网络,而是 在计算机网络体系结构模型中的第3层的名称。
互联网是由大量的异构(eterogeneous)网络通过路由器(router)相互连接起来的。 互联网使用的网络层协议是无连接的网际协议IP(Internet Protocol)和许多种路由选择协议, 因此互联网的网络层也叫做网际层或IP层。在本书中, 网络层、 网际层和IP层都是同义语。

(4)数据链路层(data link layer)

数据链路层常简称为链路层。 我们知道, 两台主机之间的数据传输, 总是在一段一段的链路上传送的, 这就需要使用专门的链路层的协议。 在两个相邻结点之间传送数据时, 数据链路层网络层交下来的 IP数据报组装成帧(framing), 在两个相邻结点间的链路上传送帧(frame)。 每一帧包括数据和必要的控制信息(如同步信息、 地址信息、 差错控制等)。
在接收数据时,控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。 这样, 数据链路层在收到一个帧后, 就可从中提取出数据部分, 上交给网络层
控制信息还使接收端能够检测到所收到的帧中有无差错。 如发现有差错, 数据链路层就简单地丢弃这个出了差错的帧, 以免继续在网络中传送下去白白浪费网络资源。 如果需要改正数据在数据链路层传输时出现的差错(这就是说, 数据链路层不仅要检错,而且要纠错),那么就要采用可靠传输协议来纠正出现的差错。 这种方法会使数据链路层的协议复杂些。

(5)物理层(physicallayer)

在物理层上所传数据的单位是比特。发送方发送1(或0)时,接收方应当收到1(或0)而不是 0 (或1)。 因此物理层要考虑用多大的电压代表 “ 1 ” 或 “ 0,以及接收方如何识别出发送方所发送的比特。 物理层还要确定连接电缆的插头应当有多少根引脚以及各引脚应如何连接。 当然, 解释比特代表的意思, 就不是物理层的任务。 请注意, 传递信息所利用的一些物理媒体, 如双绞线、 同轴电缆、 光缆、 无线信道等, 并不在物理层协议之内而是在物理层协议的下面。 因此也有人把物理层下面的物理媒体当作第0层。在互联网所使用的各种协议中, 最重要的 和最著名的就是TCP和E两个协议。 现在人们经常提到的TCP/IP并不一定是单指TCP和IP这两个具体的协议, 而往往是表示互联网所使用的整个TCP/IP协议族(protocol suite)。

图中说明的是应用进程的数据在各层之间的传递过程中所经历的变化。 这里为简单起见, 假定两台主机通过一台路由器连接起来。

假定主机1的应用进程AP1向主机2的应用进程AP2传送数据。 AP1先将其数据交给本主机的第5层(应用层)。 第5层加上必要的控制信息且就变成了下一层的数据单元。 第4层(运输层)收到这个数据单元后, 加上本层的控制信息且, 再交给第3 层(网络层),成为第3层的数据单元。依此类推。 不过到了第2层(数据链路层)后, 控制信息被分成两部分, 分别加到本层数据单元的首部(H2)和尾部(T2):而第1层(物理层)由于是比特流的传送, 所以不再加上控制信息。 请注意, 传送比特流时应从首部开始传送。

OSI参考模型把对等层次之间传送的数据单位称为该层的协议数据单元PDU (Protocol Data Unit)。这个名词现己被许多非OSI标准采用。

当这一串的比特流离开主机1 经网络的物理媒体传送到路由器时, 就从路由器的第l 层依次上升到第3层。 每一层都根据控制信息进行必要的操作, 然后将控制信息剥去, 将该层剩下的数据单元上交给更高的一层。 当分组上升到了第3层时, 就根据首部中的目的地址查找路由器中的转发表, 找出转发分组的接口, 然后往下传送到第2层, 加上新的首部和尾部后, 再到最下面的第1层, 然后在物理媒体上把每一个比特发送出去。

当这一串的比特流离开路由器到达目的站主机2时, 就从主机2的第1层按照上面讲过的方式, 依次上升到第5层。 最后, 把应用进程 AP1发送的数据交给目的站的应用进程 AP2可以用一个简单例子来比喻上述过程。 有一封信从最高层向下传。 每经过一层就包上一个新的信封, 写上必要的地址信息。 包有多个信封的信件传送到目的站后, 从第1层起,每层拆开一个信封后就把信封中的信交给它的上一层。 传到最高层后, 取出发信人所发的信交给收信人。

虽然应用进程数据要经过如图中所示的复杂过程才能送到终点的应用进程, 但这些复杂过程对用户来说, 却都被屏蔽掉了, 以致应用进程 AP1觉得好像是直接把数据交给了应用进程AP2。 同理, 任何两个同样的层次(例如在两个系统的第4层) 之间, 也好像如同 图1-19 中的水平虚线所示的那样, 把数据(即数据单元加上控制信息)通过水平虚线直接 传递给对方。 这就是所谓的 “对等层 ” (peer layers)之间的通信。 我们以前经常提到的各层 协议, 实际上就是在各个对等层之间传递数据时的各项规定。


而在实际的情况中,客户端服务器需要在同一个wifi下,并且客户端需要知道服务器的IP地址端口号,只有这样才能进行正常的通讯。

TCP通讯知识点总结相关推荐

  1. c++ char4个字节_西门子PLC的TCP通讯(不同项目下)①--TSEND_C指令

    西门子PLC的TCP通讯(不同项目下)①--TSEND_C指令 本期说一下,不同项目下的,连个西门子1200的TCP通讯,这次我们用TSEND_C和TRCV_C组合使用,这次先了解下TSEND_C指令 ...

  2. 基于QTcpSocket和QTcpServer的Tcp通讯以及QDataStream序列化数据

    为什么80%的码农都做不了架构师?>>>    最近要在QT下开发Tcp通讯,发送序列化数据以便于接收. 这里涉及到几个问题: 1.QTcpSocket.QTcpServer的通讯 ...

  3. TCP通讯处理粘包详解

    一般所谓的TCP粘包是在一次接收数据不能完全地体现一个完整的消息数据.TCP通讯为何存在粘包呢?主要原因是TCP是以流的方式来处理数据,再加上网络上MTU的往往小于在应用处理的消息数据,所以就会引发一 ...

  4. boost asio 异步实现tcp通讯

    一.前言 boost asio可算是一个简单易用,功能又强大可跨平台的C++通讯库,效率也表现的不错,linux环境是epoll实现的,而windows环境是iocp实现的.而tcp通讯是项目当中经常 ...

  5. JAVA通信编程(三)——TCP通讯

    欢迎支持笔者新作:<深入理解Kafka:核心设计与实践原理>和<RabbitMQ实战指南>,同时欢迎关注笔者的微信公众号:朱小厮的博客. 欢迎跳转到本文的原文链接:https: ...

  6. linux网络编程(二)TCP通讯状态

    linux网络编程(二)TCP通讯状态 TCP状态转换 为什么需要等待2MSL? 端口复用 TCP状态转换 tcp协议连接开始会经过三次握手,客户端和服务器开始都会处于CLOSED状态 第一次握手:客 ...

  7. 基于STM32和W5500的Modbus TCP通讯

     在最近的一个项目中需要实现Modbus TCP通讯,而选用的硬件平台则是STM32F103和W5500,软件平台则选用IAR EWAR6.4来实现. 1.移植前的准备工作 为了实现Modbus ...

  8. winpcapp配置c++网口通讯_(经验)西门子PLC的Modbus TCP通讯的一些经验

    Modbus是一种协议公开的工业通讯,被广泛使用.通过串口的是Modbus-RTU协议,通过以太网的是Modbus TCP通讯.现在的PLC都开始支持以太网通讯,因此,Modbus TCP也越来越重要 ...

  9. activeMQ的源码分析 -TCP通讯机制

    2019独角兽企业重金招聘Python工程师标准>>> activeMQ的源码分析 -TCP通讯机制 博客分类: MQ <IGNORE_JS_OP style="WO ...

  10. 用委托的方法调用TCP通讯指令列表

    需求:TCP通讯中客户端与服务端交互会有若干中指令,例如完成一个客户度登录过程,必须先建立握手连接,然后登录,假设服务端规定这个过程中,握手连接必须先建立起来,然后才能登录,不得越级.如何让程序顺序执 ...

最新文章

  1. 数据恢复 从binlog文件
  2. 使用JavaMail发送邮件,465端口开启ssl加密传输
  3. MySQL查看和修改表的存储引擎
  4. SAP Spartacus auto focus Directive响应模型变化的一些触发时机例子
  5. LoRa是怎样实现定位的
  6. 如何使用Node.js构建完整的GraphQL服务器
  7. python生成倒计时图片_python pygame--倒计时
  8. pytorch自我错误总结
  9. hibernate和jpa连接mysql_Hibernate能够连接到mysql但Spring JPA却没有
  10. 077 logging模块
  11. Git工作流(简单)
  12. Linux之LAMP架构
  13. 搭建redhat本地yum仓库,用于离线更新其它主机
  14. 迪士尼照片_迪士尼经典游戏,《狂热》和更多Linux游戏新闻
  15. java中父类创建子类的语法_Java 语言中,所创建的子类都应有一个父类。( )_学小易找答案...
  16. 【DL with Pytorch】第 3 章 :使用 DNN 的分类问题
  17. Vue百度地图标注点定位显示
  18. GO语言基础进阶教程:sync包——WaitGroup
  19. ubuntu18.04 分辨率设置
  20. 计算机多媒体技术第五章,第五章多媒体技术的发展与应用

热门文章

  1. 小旭追女神-三国乱世(裸的单点线段树更新)
  2. golang爬取Instagram内容下载地址
  3. 2010 模板下载 罗斯文_纯干货!速卖通运费模板的设置技巧!
  4. 理解图像处理中的 双线性内插法(图文说明)
  5. 手把手-AMOS全流程实操教程
  6. 电脑网线主要分类(网络传输介质)
  7. K3Cloud BOS设计 值更新 字段拼接到文本字段
  8. 心理测评全系统设计与代码实现
  9. web应用程序的部署
  10. 如何解决设备管理中的难点?