tcp协议数据解析(wireshark解析tcp协议)

      最后更新:2024-03-20 05:20:47 手机定位技术交流文章

      网络编程(五)TCP详解

      考虑最简单的情况:两台主机之间的通信。这个时候只需要一条网线把两者连起来,规定好彼此的硬件接口,如都用 USB、电压 10v、频率 2.4GHz 等,这一层就是物理层,这些规定就是物理层协议。我们当然不满足于只有两台电脑连接,因此我们可以使用交换机把多个电脑连接起来,如下图:这样连接起来的网络,称为局域网,也可以称为以太网(以太网是局域网的一种)。在这个网络中,我们需要标识每个机器,这样才可以指定要和哪个机器通信。这个标识就是硬件地址 MAC。硬件地址随机器的生产就被确定,永久性唯一。在局域网中,我们需要和另外的机器通信时,只需要知道他的硬件地址,交换机就会把我们的消息发送到对应的机器。这里我们可以不管底层的网线接口如何发送,把物理层抽离,在他之上创建一个新的层次,这就是数据链路层。我们依然不满足于局域网的规模,需要把所有的局域网联系起来,这个时候就需要用到路由器来连接两个局域网:但是如果我们还是使用硬件地址来作为通信对象的唯一标识,那么当网络规模越来越大,需要记住所有机器的硬件地址是不现实的;同时,一个网络对象可能会频繁更换设备,这个时候硬件地址表维护起来更加复杂。这里使用了一个新的地址来标记一个网络对象:IP 地址。通过一个简单的寄信例子来理解 IP 地址。我住在北京市,我朋友 A 住在上海市,我要给朋友 A 写信:因此,这里 IP 地址就是一个网络接入地址(朋友 A 的住址),我只需要知道目标 IP 地址,路由器就可以把消息给我带到。在局域网中,就可以动态维护一个 MAC 地址与 IP 地址的映射关系,根据目的 IP 地址就可以寻找到机器的 MAC 地址进行发送。这样我们不需管理底层如何去选择机器,我们只需要知道 IP 地址,就可以和我们的目标进行通信。这一层就是网络层。网络层的核心作用就是提供主机之间的逻辑通信。这样,在网络中的所有主机,在逻辑上都连接起来了,上层只需要提供目标 IP 地址和数据,网络层就可以把消息发送到对应的主机。一个主机有多个进程,进程之间进行不同的网络通信,如边和朋友开黑边和女朋友聊微信。我的手机同时和两个不同机器进行通信。那么当我的手机收到数据时,如何区分是微信的数据,还是王者的数据?那么就必须在网络层之上再添加一层:运输层:运输层通过 socket(套接字),将网络信息进行进一步的拆分,不同的应用进程可以独立进行网络请求,互不干扰。这就是运输层的最本质特点:提供进程之间的逻辑通信。这里的进程可以是主机之间,也可以是同个主机,所以在 android 中,socket 通信也是进程通信的一种方式。现在不同的机器上的应用进程之间可以独立通信了,那么我们就可以在计算机网络上开发出形形式式的应用:如 web 网页的 http,文件传输 ftp 等等。这一层称为应用层。应用层还可以进一步拆分出表示层、会话层,但他们的本质特点都没有改变:完成具体的业务需求。和下面的四层相比,他们并不是必须的,可以归属到应用层中。最后对计网分层进行小结:这里需要注意的是,分层并不是在物理上的分层,而是逻辑上的分层。通过对底层逻辑的封装,使得上层的开发可以直接依赖底层的功能而无需理会具体的实现,简便了开发。这种分层的思路,也就是责任链设计模式,通过层层封装,把不同的职责独立起来,更加方便开发、维护等等。TCP 并不是把应用层传输过来的数据直接加上首部然后发送给目标,而是把数据看成一个字节 流,给他们标上序号之后分部分发送。这就是 TCP 的面向字节流特性:面向字节流的好处是无需一次存储过大的数据占用太多内存,坏处是无法知道这些字节代表的意义,例如应用层发送一个音频文件和一个文本文件,对于 TCP 来说就是一串字节流,没有意义可言,这会导致粘包以及拆包问题,后面讲。前面讲到,TCP 是可靠传输协议,也就是,一个数据交给他,他肯定可以完整无误地发送到目标地址,除非网络炸了。他实现的网络模型如下:对于应用层来说,他就是一个可靠传输的底层支持服务;而运输层底层采用了网络层的不可靠传输。虽然在网络层甚至数据链路层就可以使用协议来保证数据传输的可靠性,但这样网络的设计会更加复杂、效率会随之降低。把数据传输的可靠性保证放在运输层,会更加合适。可靠传输原理的重点总结一下有:滑动窗口、超时重传、累积确认、选择确认、连续 ARQ。停止等待协议要实现可靠传输,最简便的方法就是:我发送一个数据包给你,然后你跟我回复收到,我继续发送下一个数据包。传输模型如下:这种“一来一去”的方法来保证传输可靠就是停止等待协议(stop-and-wait)。不知道还记不记得前面 TCP 首部有一个 ack 字段,当他设置为 1 的时候,表示这个报文是一个确认收到报文。然后再来考虑另一种情况:丢包。网络环境不可靠,导致每一次发送的数据包可能会丢失,如果机器 A 发送了数据包丢失了,那么机器 B 永远接收不到数据,机器 A 永远在等待。解决这个问题的方法是:超时重传。当机器 A 发出一个数据包时便开始计时,时间到还没收到确认回复,就可以认为是发生了丢包,便再次发送,也就是重传。但重传会导致另一种问题:如果原先的数据包并没有丢失,只是在网络中待的时间比较久,这个时候机器 B 会受到两个数据包,那么机器 B 是如何辨别这两个数据包是属于同一份数据还是不同的数据?这就需要前面讲过的方法:给数据字节进行编号。这样接收方就可以根据数据的字节编号,得出这些数据是接下来的数据,还是重传的数据。在 TCP 首部有两个字段:序号和确认号,他们表示发送方数据第一个字节的编号,和接收方期待的下一份数据的第一个字节的编号。停止等待协议的优点是简单,但缺点是信道利用率太低。假定AB之间有一条直通的信道来传送分组这里的TD是A发送分组所需要的时间(显然TD = 分组长度 / 数据速率)再假定TA是B发送确认分组所需要的时间(A和B处理分组的时间都忽略不计)那么A在经过TD+RTT+TA时间后才能发送下一个分组,这里的RTT是往返时间,因为只有TD是采用来传输有用的数据(这个数据包括了分组首部,如果可以知道传输更精确的数据的时间,可以计算的更精确),所有信道利用率为为了提高传输效率,发送方可以不使用低效率的停止等待协议,而是采用流水线传输:就是发送方可以连续的发送多个分组,不必每发完一个分组就停下来等待对方的确认。这样可使信道上一直有数据不间断地在传送。显然这种传输方式可以获得很高的信道利用率停止等待协议已经可以满足可靠传输了,但有一个致命缺点:效率太低。发送方发送一个数据包之后便进入等待,这个期间并没有干任何事,浪费了资源。解决的方法是:连续发送数据包。也就是下面介绍的连续ARQ协议和滑动窗口协议连续 ARQ 协议模型如下:和停止等待最大的不同就是,他会源源不断地发送,接收方源源不断收到数据之后,逐一进行确认回复。这样便极大地提高了效率。但同样,带来了一些额外的问题:发送是否可以无限发送直到把缓冲区所有数据发送完?不可以。因为需要考虑接收方缓冲区以及读取数据的能力。如果发送太快导致接收方无法接受,那么只是会频繁进行重传,浪费了网络资源。所以发送方发送数据的范围,需要考虑到接收方缓冲区的情况。这就是 TCP 的流量控制。解决方法是:滑动窗口。基本模型如下:在 TCP 的首部有一个窗口大小字段,他表示接收方的剩余缓冲区大小,让发送方可以调整自己的发送窗口大小。通过滑动窗口,就可以实现 TCP 的流量控制,不至于发送太快,导致太多的数据丢失。连续 ARQ 带来的第二个问题是:网络中充斥着和发送数据包一样数据量的确认回复报文,因为每一个发送数据包,必须得有一个确认回复。提高网络效率的方法是:累积确认。接收方不需要逐个进行回复,而是累积到一定量的数据包之后,告诉发送方,在此数据包之前的数据全都收到。例如,收到 1234,接收方只需要告诉发送方我收到 4 了,那么发送方就知道 1234 都收到了。第三个问题是:如何处理丢包情况。在停止等待协议中很简单,直接一个超时重传就解决了。但,连续 ARQ 中不太一样。例如:接收方收到了 123 567,六个字节,编号为 4 的字节丢失了。按照累积确认的思路,只能发送 3 的确认回复,567 都必须丢掉,因为发送方会进行重传。这就是GBN(go-back-n)思路。但是我们会发现,只需要重传 4 即可,这样不是很浪费资源,所以就有了:选择确认 SACK。在 TCP 报文的选项字段,可以设置已经收到的报文段,每一个报文段需要两个边界来进行确定。这样发送方,就可以根据这个选项字段只重传丢失的数据了。第四个问题是:拥塞控制的问题也是通过窗口的大小来控制的,但是检测网络满不满是个挺难的事情,所以 TCP 发送包经常被比喻成往谁管理灌水,所以拥塞控制就是在不堵塞,不丢包的情况下尽可能的发挥带宽。水管有粗细,网络有带宽,即每秒钟能发送多少数据;水管有长度,端到端有时延。理想状态下,水管里面的水 = 水管粗细 * 水管长度。对于网络上,通道的容量 = 带宽 * 往返时延。如果我们设置发送窗口,使得发送但未确认的包为通道的容量,就能撑满整个管道。如图所示,假设往返时间为 8 秒,去 4 秒,回 4 秒,每秒发送一个包,已经过去了 8 秒,则 8 个包都发出去了,其中前四个已经到达接收端,但是 ACK 还没返回,不能算发送成功,5-8 后四个包还在路上,还没被接收,这个时候,管道正好撑满,在发送端,已发送未确认的 8 个包,正好等于带宽,也即每秒发送一个包,也即每秒发送一个包,乘以来回时间 8 秒。如果在这个基础上调大窗口,使得单位时间可以发送更多的包,那么会出现接收端处理不过来,多出来的包会被丢弃,这个时候,我们可以增加一个缓存,但是缓存里面的包 4 秒内肯定达不到接收端课,它的缺点会增加时延,如果时延达到一定程度就会超时重传TCP 拥塞控制主要来避免两种现象,包丢失和超时重传,一旦出现了这些现象说明发送的太快了,要慢一点。具体的方法就是发送端慢启动,比如倒水,刚开始倒的很慢,渐渐变快。然后设置一个阈值,当超过这个值的时候就要慢下来慢下来还是在增长,这时候就可能水满则溢,出现拥塞,需要降低倒水的速度,等水慢慢渗下去。拥塞的一种表现是丢包,需要超时重传,这个时候,采用快速重传算法,将当前速度变为一半。所以速度还是在比较高的值,也没有一夜回到解放前。到这里关于 TCP 的可靠传输原理就已经介绍得差不多。最后进行一个小结:当然,这只是可靠传输的冰山一角,感兴趣可以再深入去研究
      网络编程(五)TCP详解

      TCP/IP详解卷一 ——tcp

      即使端口处于2MSL状态,使用该选项,仍然能够在该端口建立连接。服务器常会设置该选项,以防服务器重启。如果在TIME_WAIT时间内,收到了对端发送来的数据报(不是重置报文段都行),那么该状态将被破坏,称为时间等待错误。原因是,当收到报文段以后,通常Seq是旧的,所以本端就会发送ACK,对端已经关闭或者是别的连接,就会发送RST,导致TIME_WAIT状态被破坏。但是许多系统规定,TIME_WAIT状态是不对重置报文段做出反应。两端同时发送FIN,两端又同时ACK。又同时进入TIME_WAIT当处于TIME_WAIT的主机崩溃以后,重启,然后需要等待相当与一个MSL的时间才能建立新的连接。这段时间成为静默时间。当一段发现到达的报文段对相关连接(也就是进程,套接字对)而言不正确的时候,TCP就会发送一个重置报文段,从而导致对端的连接快速拆卸(也就是结束吧!)。重置报文段的ACK位必须有,而且ACK的值必须在正确的窗口范围内,这样可以防止被攻击。FIN正常关闭一条连接成为有序释放,通常不会出现丢失数据的情况。重置报文段终止一条连接成为终止释放。重置报文段在任何时候都可以发送,代替FIN来终止连接,且不学校对端ACK终止报文段特性:当该数值设置为0,那么也意味着,不会再连接终止之前为了确保本端缓存中的数据都发送出去而等待。TCP在发送数据时会设置计时器,如果计时器超时认为受到数据确认信息,就会引发相应的超时,或给予计时器的重传操作,计时器超时时成为重传超时(RTO)。TCP累计确认无法返回新的ACK,或者当ACK包含选择确认信息(SACK)时,表明出现书序数据报,空洞。就会引起快速重传。若RTO短与RTT,那么没分都会重传,反之,整个网络利用率就会随之下降。RTT样本:TCP在收到数据后会返回确认信息ACK,该信息中携带一个字节的数据,测量传输该确认需要的时间,该测量结果成为RTT样本。每个连接的RTT军独立计算。如何根据RTT来设置RTO,有如下的方法公式: SRTT=a*SRTT+(1-a)RTT ,a取 0.8-0.9 。当TCP运行在RTT变化较大的网络中,无法取得期望的结果。以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补因为丢失ACK,或者实际RTT显著增长,可能出现伪超时的现象。以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补每个包可以选择各自的传送路径。某些高级路由器的采用多个并行数据链路,不同的处理演示也会导致包的离开顺序和到达顺序不匹配包的失序会造成重传,很近单嘛,前面一个小号的Seq没到达,后面的先到达,那么ACK就会 重复当TCP超时重发是,循序执行重新租宝,发送送一个更大的报文段提高性能,不超过MSS和MTU。出现在每次传送的包较小,又丢包的情况每个交互键通常会生成一个单独的数据报,也就是每个按键是独立传输的。ssh调用一个shell,对客户端输入的字符做出辉县,因此,每个字符生成4个tcp数据段,客户端的交互按键输入,服务器对按键的ACK,服务器生成的辉县,客户端对回显的ACK。通常第二段和第三段合并,成为捎带延时确认。PSH位设置,意味着发送端的缓存为空,也就是没什么可以发送了。许多情况下,TCP并不是对每个到来的包都单独的ACK,利用累计ACK可以确认之前的ACK。累计确认可以允许TCP延时一段时间发送ACK,以便将ACK和相同方向上需要传输的数据结合发。这种捎带传输的方法常用于批量数据传输。不能任意的延迟ACK,会造成重传。同时当失序发生时,必须立刻传送ACK。系统可以设置,一般延时为200-600毫秒。该算法要求,当TCP连接中有在传数据(那些已发送,但是未确认的数据)时,小的报文段就不能被发送,知道所有的数据都受到ACK。并且受到ACK后,TCP收集这些小的数据,整合到一个报文段中发送。这种方法破事TCP遵循等停规程,只有收到所有传送数据的ACK后才能继续发送新数据。该算法的不同之处在于他实现了自时钟控制,ACK返回越快,传输也越快。在相对高延迟的广域网中,更需要减小小报文的数目,该算法使得单位时间内发送的报文数目更少,RTT控制发包速率。该算法减少小包数目的同时,也增大了传输时延,也就是总的发送时间。窗口大小表明本端可用缓存大小,对端传送的数据不应该超过改大小。也表明对端发送的数据的最大大小为TCP头部ACK号和窗口大小字段之和。也就是Seq = ACK+MSSTCP活动的两端都维护一个发送窗口结构和接受窗口结构。TCP以字节为单位维护窗口结构。每个TCP报文段都包含ACK号和窗口通告信息,TCP发送端可以据此调节窗口结构。窗口左边界不能左移。窗口的动作分为,关闭(收到ACK,左边右移),打开(MSS扩大,右边右移),收缩(MSS减小,右边左移)当收到ACK号增大,而MSS不变时窗口向前滑动当当左边界与右边界相等时,成为零窗口,此时发送端不能在发送新的数据,这种情况下,TCP开始探测对端窗口,伺机增大窗口。当接受窗口值变为0是,可以邮箱的组织发送端继续发送,知道窗口大小回复为非0值。当接收端窗口得到可用空间是,就会给发送端传输一个窗口更新,告知器可以继续发送数据,这样的这样的窗口更新通常不包含数据,成为纯ACK,因此不能保证传输的可靠性。如果一端的窗口更新ACK丢失,通信双方就会处于等待状态。为避免这种情况发生。发送端会采用一个持续计时器间歇性的查询接收端,看其窗口是否已经增长。持续计时器会触发窗口探测的传输,强制要求对端返回ACK。窗口探测包包含一个字节数据,采用TCP传输,因此可以避免窗口更新丢失导致的死锁。因为包含一个字节数据Seq改变,接受端必须处理,如果接受就会ACK。窗口大小还是0,那么就会丢弃该报,没有响应。这时候发送端会持续的发送窗口探测包。当接收端通告窗口较小,或者发送端发送的数据较小。这样数据报的有效携带率小,耗费网络资源多。避免方法以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补
      TCP/IP详解卷一 ——tcp

      php 如何解析通过tcp协议发过来的数据

      //创建socket监听端口 $socket = socket_create_listen("55555");//连接失败给出错误信息if(!$socket){exit("Failed to create socket!n");}while(true){ $client = socket_accept($socket); //接受一个Socket连接!
      php 如何解析通过tcp协议发过来的数据

      TCP协议解析

      主要特点:面向连接、面向字节流、全双工通信、通信可靠。优缺点:应用场景:要求通信数据可靠时,即 数据要准确无误地传递给对方。如:传输文件:HTTP、HTTPS、FTP等协议;传输邮件:POP、SMTP等协议ps:首部的前 20 个字节固定,后面有 4n 字节根据需要增加。故 TCP首部最小长度 = 20字节(最大60个字节)。TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。重要字段:客户端与服务器来回共发送三个TCP报文段来建立运输连接,三个TCP报文段分别为:(1)客户端A向服务器B发送的TCP请求报段“SYN=1,seq=x”;(2)服务器B向客户端A发送的TCP确认报文段“SYN=1,ACK=1,seq=y,ack=x+1”;(3)客户端A向服务器B发送的TCP确认报文段“ACK=1,seq=x+1,ack=y+1”。ps:在建立TCP连接之前,客户端和服务器都处于关闭状态(CLOSED),直到客户端主动打开连接,服务器才被动打开连接(处于监听状态 = LISTEN),等待客户端的请求。TCP 协议是一个面向连接的、安全可靠的传输层协议,三次握手的机制是为了保证能建立一个安全可靠的连接。通过上述三次握手,双方确认自己与对方的发送与接收是正常的,就建立起一条TCP连接,即可传送应用层数据。ps:因 TCP提供的是全双工通信,故通信双方的应用进程在任何时候都能发送数据;三次握手期间,任何1次未收到对面的回复,则都会重发。为什么两次握手不行呢?结论:防止服务器接收了早已经失效的连接请求报文,服务器同意连接,从而一直等待客户端请求,最终导致形成死锁、浪费资源。ps:SYN洪泛攻击:(具体见下文)为什么不需要四次握手呢?SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时,客户机首先发出一个 SYN 消息,服务器使用 SYN-ACK 应答表示接收到了这个消息,最后客户机再以 ACK确认序号标志消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接,数据才可以在客户机和服务器之间传递。如何来解决半连接攻击?如何来解决全连接攻击?请注意,现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL(MSL:最长报文段寿命)后,客户端才能进入到 CLOSED 状态,然后撤销传输控制块,结束这次 TCP 连接。当然如果服务器一收到 客户端的确认就进入 CLOSED 状态,然后撤销传输控制块。所以在释放连接时,服务器结束 TCP 连接的时间要早于客户端。TCP是全双工的连接,必须两端同时关闭连接,连接才算真正关闭。简言之,客户端发送了 FIN 连接释放报文之后,服务器收到了这个报文,就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据,传送完毕之后,服务器才会发送 FIN 连接释放报文,对方确认后就完全关闭了TCP连接。举个例子:A 和 B 打电话,通话即将结束后,A 说“我没啥要说的了”,B回答“我知道了”,但是 B 可能还会有要说的话,A 不能要求 B 跟着自己的节奏结束通话,于是 B 可能又巴拉巴拉说了一通,最后 B 说“我说完了”,A 回答“知道了”,这样通话才算结束。ps:设想这样一个情景:客户端已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然,服务器以后就不能再收到客户端发来的数据。因此,应当有措施使服务器不要再白白等待下去。这就需要使用TCP的保活计时器。基本原理:tcp11种状态及变迁其实基本包含在正常的三次握手和四次挥手中,除开CLOSING。正常的三次握手包括4中状态变迁:服务器打开监听(LISTEN)->客户端先发起SYN主动连接标识->服务器回复SYN及ACK确认->客户端再确认即三次握手TCP连接成功。这里边涉及四种状态及变迁:正常的四次握手包含6种tcp状态变迁,如主动发起关闭方为客户端:客户端发送FIN进入FIN_WAIT1 -> 服务器发送ACK确认并进入CLOSE_WAIT(被动关闭)状态->客户端收到ACK确认后进入FIN_WAIT2状态 -> 服务器再发送FIN进入LAST_ACK状态 -> 客户端收到服务器的FIN后发送ACK确认进入TIME_WAIT状态 -> 服务器收到ACK确认后进入CLOSED状态断开连接 -> 客户端在等待2MSL的时间如果期间没有收到服务器的相关包,则进入CLOSED状态断开连接。CLOSING状态:连接断开期间,一般是客户端发送一个FIN,然后服务器回复一个ACK,然后服务器发送完数据后再回复一个FIN,当客户端和服务器同时接受到FIN时,客户端和服务器处于CLOSING状态,也就是此时双方都正在关闭同一个连接。在进入CLOSING状态后,只要收到了对方对自己发送的FIN的ACK,收到FIN的ACK确认就进入TIME_WAIT状态,因此,如果RTT(Round Trip Time TCP包的往返延时)处在一个可接受的范围内,发出的FIN会很快被ACK从而进入到TIME_WAIT状态,CLOSING状态持续的时间就特别短,因此很难看到这种状态。我们知道网络层,可以实现两个主机之间的通信。但是这并不具体,因为,真正进行通信的实体是在主机中的进程,是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机,但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。应用场景:UDP协议比TCP协议的效率更高,TCP协议比UDP协议更加安全可靠。下面主要对数据传输出现错误/无应答/堵塞/超时/重复等问题。注意:TCP丢包:TCP是基于不可靠的网路实现可靠传输,肯定会存在丢包问题。如果在通信过程中,发现缺少数据或者丢包,那边么最大的可能性是程序发送过程或者接受过程中出现问题。总结:为了满足TCP协议不丢包,即保证可靠传输,规定如下:注意:TCP丢包有三方面的原因,一是网络的传输质量不好,二是安全策略,三是服务器性能瓶颈先理解2个基础概念:发送窗口、接收窗口工作原理:注意点:关于滑动窗口的知识点:滑动窗口中的数据类型:ARQ解决的问题:出现差错时,让发送方重传差错数据:即 出错重传类型:流量控制和拥塞控制解决的问题:当接收方来不及接收收到的数据时,可通知发送方降低发送数据的效率:即 速度匹配流量控制:注意:拥塞控制:慢开始与拥塞避免:快重传和快恢复:补充:流量控制和拥塞控制的区别什么情况造成TCP粘包和拆包?解决TCP粘包和拆包的方法:传输层无法保证数据的可靠传输,只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式,只是实现不在传输层,实现转移到了应用层。最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理,可靠UDP的简单设计。https://www.jianshu.com/p/65605622234bhttp://www.open-open.com/lib/view/open1517213611158.htmlhttps://blog.csdn.net/dangzhangjing97/article/details/81008836https://blog.csdn.net/qq_30108237/article/details/107057946https://www.jianshu.com/p/6c73a4585eba
      TCP协议解析

      TCP-IP详解卷1:协议读书笔记_2

      在TCP/IP协议族中,链路层主要有三个目的: (1)为IP模块发送和接受IP数据报(2)为ARP模块发送ARP请求和接受ARP应答(3)为RARP发送RARP请求和接收RARP应答以太网是当今TCP/IP采用的主要的局域网技术。它采用一种称作CSMA/CD的额媒体接入方法,其意思是带冲突检测的载波侦听多路接入。它的速率为10MB/S,地址为48bit。主机需求RFC要求每个Internet主机都与10MB/s的以太网电缆相连接:1)必须能发送和接受采用RFC894(以太网)封装格式的分组2)应该能接受与RFC894混合的RFC1024(IEEE082)封装格式的分组3)也许能够发送采用RFC1024格式封装的分组最常使用的封装格式是RFC 894定义的格式。下图显示了两种形式的封装格式。图中每个方框下面的数字是它们的字节长度。两种帧格式都采用48bit(6字节)的目的地址和源地址。ARP和RARP协议对32位bit的IP地址和48bit的硬件地址进行映射。接下来两个字节在两种帧格式中互不相同。RFC1024定义的长度字段是指它后续数据的字节长度,但不包括CRC校验码。RFC894定义了后续数据的类型。RFC1024的有效长度和RFC894有效类型值都不相同,所以,可以对两种帧格式进行区分。RFC894类型后面就是数据;而RFC1024后有哦3个字节的802.2LLC和5个字节的802.2SNAP。目的服务访问点和源服务访问点的值都设为0Xaa。Ctrl字段的值设为3。随后的3个字节org code都置为0。再接下来两个字节类型和以太网格式一样。CRC字段用于帧内后续字节差错的循环冗余码检验。RFC893描述了另一种用于以太网的封装格式,称作尾部封装。在以太网数据帧中,开始的那部分是边长的字段;将其移动到尾部(CRC之前),这样将数据复制到内核时,就可以把数据帧的数据部分映射到一个硬件页面,节省内存到内存的赋值过程SLIP全称是Serial Line IP。它是一种在串行线路行对IP数据报进行封装的简单形式。SLIP适用于家庭中每台计算机几乎都有的RS-232串行端口和高速调制解调器接入Internet。下面的规则描述了SLIP协议定义的帧格式:1)IP数据报以一个END(0xc0)的特殊字符结束。同时,为了防止数据报到来之前的线路噪声也被当成数据报内容,大多数实现在数据报的开始处也传一个END字符。2)如果IP数据报的某个数据是END,那么就要联系传输两个字节0xdb和0Xdc来取代它。0xdb称为SLIP的ESC字符,但是它的值和ASCII码的ESC字符0x1b不同。3)如果IP报文中某个字符为SLIP的ESC字符,那么就要连续传输两个0xdb和0xdd来取代它。SLIP的图示:SLIP的缺陷:1)每一段必须知道对方的IP地址,没有办法把本端的IP地址通知给另一端。2)数据帧中没有类型字段。如果一条串行线路用于SLIP,那么它不能同时使用其他协议。3)SLIP没有在数据帧中加上校验和。SLIP线路行有许多小的TCP分组进行交换。为了传送1个字节的数据需要20个字节的IP首部和20个字节的TCP首部,总数超过40个字节。于是有了CSLIP的新协议,即压缩SLIP。一般可以把上面40个字节压缩到3-5个字节。PPP点对点协议,包含了一下三个部分:1)在串行链路上封装IP数据报的方法。PPP既支持数据为8位的无奇偶校验的异步模式,还支持面向比特的同步链接。2)建立、配置以及测试数据链路的链路控制协议(LCP)。它允许通信双发进行协商,以确定不同的选项。3)针对不同网络层协议的网络控制协议体系。PPP数据帧都是以标志字符0x7e开始和结束。紧接着是一个地址字节,值始终为0x03的字节字符。接下来是协议字段,类似于以太网中类型字段的功能。0X0021代表IP数据报;0XV021代表链路控制数据;0x8021代表信息是网络控制数据。CRC字段,是一个循环冗余校验码,以检测数据帧中的错误。总的来说,PPP比SLIP具有以下优点:1.PPP支持单根串行线路上运行多种协议;2.每一帧都有循环冗余校验;3.通信双方可以进行IP地质的动态协商(使用IP网络控制协议);4.与CSLIP类似,对TCP和IP报文首部进行压缩;5.链路控制协议可以对多个数据链路选项进行设置。大多数产品都支持环回接口,以允许运行在同一主机上的客户程序和服务器程序通过TCP/IP进行通信。A类网络号127是为环回接口预留的。根据惯例,大多数系统把IP地址127.0.0.1分配给这个接口,并命名为localhost。图中的关键点是:1)传给环回地址(一般是127.0.0.1)的任何数据均作为IP输入。2)创个广播地址和多播地址的数据报复制一份传给环回接口,然后送到以太网上。这是因为广播传送和多播传送的定义包含主机本身。3)任何传给主机地址的数据均送到环回接口。链路层的数据帧的最大传输字节称作MTU,最大传输单元。不同类型的网络大多数都有一个上限。如果IP层有一个数据报要传,而且数据的长度比链路层的MTU还大,那么IP层就需要进行分片,把数据报分成若干份,这样每一片都小于MTU。 当在同一网络的两台主机互相进行通信时,该网络的MTU是非常重要的。但是两台主机的通信要通过多阿哥网络,那么每个网络的链路层可能有不同的MTU,重要的就不是两台主机所在网络的MTU了,而是两台通信主机路径中的最小MTU。它被称作路径MTU。
      TCP-IP详解卷1:协议读书笔记_2

      本文由 在线网速测试 整理编辑,转载请注明出处,原文链接:https://www.wangsu123.cn/news/306062.html

          热门文章

          文章分类