TCPIP协议栈的基本工作原理

TCP/IP协议栈的基本工作原理

TCP/IP是互联网的核心协议，也是大多数网络应用的核心协议。就前面一段时间面试中问到的TCP/IP问题，这里给出一个简单的小结。

TCP由RFC793、RFC1122、RFC1323、RFC2001、RFC2018以及RFC2581定义。

(1) TCP概述

a. TCP提供的是面向连接的全双工服务。

TCP所有的数据会匹配到由源地址，目的地址，源端口，目的端口构成的一个TCP连接之上。TCP连接是一种需要建立的资源，可以通过之后会讲到的握手机制来完成。UDP是一种基于尽力而为机制的协议，不存在UDP连接资源的建立，资源的处理往往由应用层协议代劳了。

b. TCP是提供的可靠服务。

TCP有确认机制来保证数据包的可靠到达，

TCP有CRC校验机制来保证数据包的无差错性，UDP的CRC是可选的，

TCP会重新排序乱序的数据包和丢弃重复的数据，

TCP能够提供流量控制机制，使用滑动窗口算法，

TCP能提供拥塞控制与恢复机制，存在多种TCP拥塞控制模型，

TCP能协商发送的数据报文长度。

TCP报头。

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Port | Destination Port |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Sequence Number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Acknowledgment Number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Data | |U|A|P|R|S|F| |

| Offset| Reserved |R|C|S|S|Y|I| Window |

| | |G|K|H|T|N|N| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Checksum | Urgent Pointer |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Options | Padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| data |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TCP Header Format

对于TCP头的标记位，SYN标记只在三次握手(或四次握手)的时候的被置位，ACK标记会在

握手之后所有的TCP报文中被置位。当然也有一些特殊情况，比如有些情况下RST报文不会置位ACK。

这些规则也许在配置复杂的ACL中有用。

(2) TCP协议栈的状态机(摘自RFC793)

a. TCP连接的建立。TCP连接的建立有主动打开，被动打开以及同时打开三种情况。

三次握手比较清楚，要强调的是ISN，就是初始序列号的选择问题，序列号是32位的，针对不同的OS，初始序列号的选择往往也是有规律的。

TCP传输的最大报文长度也是在三次握手中协商的。具体说是在也仅在SYN报文中协商的。MSS = MTU - ip_header_len - tcp_header_len。MSS这里也是为了防止分片，提高网络带宽利用率。

TCP三次握手中，最后一个报文ACK，不需要再有额外的确认机制，如果这个ACK在网络中丢弃了，TCP协议栈也有其他的机制来处理。

除了三次握手，还有一种很特殊的应用情况，就是TCP两端同时打开的情况(发送syn)，这种情况没有描述在上面的状态机中。

举例子来说，A通过源端口7777发起到B的目的端口8888的连接的同时，B也通过源端口8888发起对A的目的端口7777的TCP连接。

b. TCP连接的关闭

TCP连接的关闭也有主动关闭，被动关闭和同时关闭三种情况，这三种情况在上面的TCP状态机中都有描述。

TCP连接的关闭需要报文四次交互，因为TCP是一个全双工的服务，所以每个方向的连接都关闭后，TCP的连接才是完整的拆除。

状态机中，主动关闭和同时关闭最后都会进入到一个TIME_WAITE状态。针对TCP主动关闭的最后一个报文应该是ACK，确认对端的FIN报文。这个状态的概念是该TCP连接的资源并没有完全释放，因为还要确保最后一个ACK报文能够无误的到达对端，确认对端的FIN，否则就仍然要重传ACK。

这个等待的过程(或者资源没有完全释放的过程)需要等待2MSL时间(考虑报文一次往返)。MSL是最大报文生存时间，RFC793中为2分钟，根据不同的TCP实现，一般是30s或者1分钟。

所以在TIME_WAITE状态内，该TCP连接所使用的端口和连接资源，不能被继续使用。但是很多TCP实现并没有这个限制，只要新的TCP连接所使用的ISN大于TIME_WAITE状态TCP 连接所使用的最后序号即可。实现中往往使用

new ISN = latest ISN in time_waite + 128000

IP报文的最大生存时间是TTL值，TCP报文的最大生存时间是MSL，二层上没有报文最大生存时间的概念，存在风暴的可能。

(3) TCP的滑动窗和定时器

a. TCP的报文确认机制。

TCP使用的是滑动窗口机制来发送数据流，所以TCP协议允许连续发送多个TCP分组而不等待对端的确认。所以发送的分组数据和确认不是一对一的关系。

TCP中，对数据的确认往往是延迟的，一般情况是两个TCP数据对应一个确认，在时延定时器没有溢出的情况下。如果时延定时器溢出了，那么自然也会发送确认报文。

但是，针对存在交互大量微小报文的TCP应用，过于频繁的确认会导致网络利用率的低效，所以TCP支持一种Nagle算法。

b. 延时定时器

当TCP收到报文时候，启动延时定时器，比如200ms。

c. Nagle算法

TCP连接上只能存在一个未被确认的微小报文(41字节的TCP报文)，在该确认到达前，TCP 仅仅收集微小报文，当确认到达后，以一个分组的形式发出去。

当然，某些应用需要关闭Nagle算法。

d. 滑动窗口机制

窗口合拢(左移)：在收到对端数据后，自己确认了数据的正确性，这些数据会被存储到缓冲区，等待应用程序获取。但这时候因为已经确认了数据的正确性，需要向对方发送确认响应ACK，又因为这些数据还没有被应用进程取走，这时候便需要进行窗口合拢，缓冲区的窗口左边缘向右滑动。注意响应的ACK序号是对方发送数据包的序号，一个对方发送的序号，可能因为窗口张开会被响应（ACK）多次。

窗口张开(右移)：窗口收缩后，应用进程一旦从缓冲区中取出数据，TCP的滑动窗口需要进行扩张，这时候窗口的右边缘向右扩张，实际上窗口这是一个环形缓冲区，窗口的右边缘扩张会使用原来被应用进程取走内容的缓冲区。在窗口进行扩张后，需要使用ACK通知对端，这时候ACK的序号依然是上次确认收到包的序号。

窗口收缩，窗口的右边缘向左滑动，称为窗口收缩，Host Requirement RFC强烈建议不要这样做，但TCP必须能够在某一端产生这种情况时进行处理。

e. 重传定时器

目的是为了获得对端的确认报文。如果多次重传仍然没有获得确认，则会发送复位报文RST。

这里我们再来看一下TCP的三次握手。

A(发起端) ---> syn ---> B(服务器)

A(发起端) <--- syn/ack <--- B(服务器)

A(发起端) ---> ack ? B(服务器)

如果TCP客户端A的最后一个ACK丢失了，TCP服务器B没有收到，会是一种什么情况？这个时候A已经进入到了Establish状态，然而B还只是Syn_Recev状态，所以服务器会重传syn/ack报文，只到连接的最终建立。但是客户端A已经到建立状态了，所以A是有可能发送TCP数据给服务器B的。

所以TCP的两端，最终状态机是有可能不一致的。

后面会详细讲述重传和拥塞控制机制。

f. 坚持定时器

由于TCP没有对ACK的确认机制，所以当接收端窗口从0恢复到一定值的时候，如果接收端发给发送端的ACK报文(标识窗口大小)丢失了，发送端就永远不知道接收端的窗口恢复情况了。

所以发送端会定时发送带一个字节的ACK给接收端，查看接收端的确认报文中的窗口信息。

g. 保活定时器

由于物理原因，处于IDLE状态的TCP连接一端崩溃的时候，TCP有保活机制来判断对端是否仍然工作。这个设计存在争议，也许应用层应该实现该功能。RFC1122中有描述，保活定时器默认是关闭的。下面截取了一些RFC描述。

Implementors MAY include "keep-alives" in their TCP implementations, although this practice is not universally accepted. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection, and they MUST default to off.

(4) TCP拥塞控制算法：慢启动、拥塞避免、快速重传和快速恢复

针对拥塞控制，主要有四种模型，即TCP TAHOE，TCP RENO，TCP NEWRENO和TCP SACK。TCP TAHOE模型是最早的TCP协议之一，它由Jacobson提出。

Jacobson观察到，TCP报文段（TCP Segment）丢失有两种原因，其一是报文段损坏，其二是网络阻塞，而当时的网络主要是有线网络，不易出现报文段损坏的情况，网络阻塞为报文段丢失的主要原因。针对这种情况，TCP TAHOE对原有协议进行了性能优化，其特点是，在正常情况下，通过重传计时器是否超时和是否收到重复确认信息（dupack）这两种丢包监测机制来判断是否发生丢包，以启动拥塞控制策略；在拥塞控制的情况下，采用慢速启动（Slow Start）算法和“拥塞避免”（Congestion Avoidance）算法来控制传输速率。1990年出现的TCP Reno版本增加了“快速重传”（Fast Retransmit）、“快速恢复”（Fast Recovery）算法，避免了网络拥塞不严重时采用“慢启动”算法而造成过度减小发送窗口尺寸的现象，这样TCP的拥塞控制就主要由这4个核心算法组成。

a. 超时与重传

RTT的计算与RTO的计算

b. 慢启动和拥塞避免算法

慢启动算法的目的是为了保证TCP发送方发送分组的速率应该匹配收到该分组确认报文的速率，这样的设计能够应用于低速链路的广域网应用。为了实现慢启动机制，为TCP连接增加了一个新的窗口，拥塞窗口cwnd，该窗口初始化为一个报文段(非一个字节，而是一个TCP

最大传输报文段大小，MSS)。这样一个方向上的TCP连接有两个窗口，一个是接收窗口用于接收方的流量控制，一个是拥塞窗口用于发送方的流量控制。发送方以这两个窗口中的小值作为方式上限。

慢启动算法：指数算法，cwnd默认为1，当收到一个ack确认时候，cwnd增加为2，当收到两个ack确认时候，cwnd增加为4，接着8，...

拥塞避免算法的目的，是为了防止中间路由器由于网络拥塞引起的数据包超时或者丢包。拥塞避免算法需要用到两个变量，一个是cwnd窗口大小，一个是ssthresh慢启动阈值，对于一个给定的初始连接，cwnd为1，ssthresh为65535。

当拥塞发生(超时或者重复确认)，当拥塞发生时候，ssthresh被设置为cwnd和接收窗口中小值的一半，如果是超时引起的拥塞，则cwnd设置为1。

拥塞避免算法：如果cwnd大于ssthresh，每收到一个数据报文的确认，cwnd=cwnd+1/cwnd，cwnd窗口大小单位仍然是mss。

拥塞避免算法其实是和慢启动配合使用的。cwnd和ssthresh都是动态的值，虽然初始值为1和65535。

当真正拥塞发生的时候，如果是超时或重复ack引起的拥塞，ssthreash会置为cwnd和接收窗口大小的一半，cwnd会降为1，然后执行慢启动算法，直到cwnd大于ssthresh的时候，执行拥塞避免算法；

在慢启动算法期间和拥塞避免算法期间，TCP的发送速率都是在增长的，只是一个是指数增长方式，一个是线性增长方式。

c . 快速重传和快速恢复算法

TCP连接中有两种情况会引起重复的ack，一种是乱序报文，一种是丢包。

快速重传：当发送方收到三个重复的ack后，不会进入慢启动状态，而是立刻重传丢失的报文。因为只有接收方收到新的报文段的时候，才会发送重复的ack，这表明TCP连接上仍然有数据流动，所以应该避免使用慢启动降速。

快速恢复：

第一步，当收到第三个重复的ack的时候，ssthresh设置为当前cwnd的一半，重传丢失的报文。设置cwnd为ssthresh加上3倍的报文段大小(cwnd=cwnd/2 + 3)。

第二步，每收到一个重复的ack，cwnd增加1并发送一个分组。

第三步，当下一个确认新数据的ack到达的时候，设置cwnd为上面第一步中ssthresh值，这个ack应该是对重传报文的确认，同时也是对丢包后面的中间报文的确认。

最后，在收到三个重复ack的情况下，速度减半。

快速重传算法首次出现在4.3BSD的Tahoe版本，快速恢复首次出现在4.3BSD的Reno版本，也称之为Reno版的TCP拥塞控制算法。

可以看出Reno的快速重传算法是针对一个包的重传情况的，然而在实际中，一个重传超时可能导致许多的数据包的重传，因此当多个数据包从一个数据窗口中丢失时并且触发快速重传和快速恢复算法时，问题就产生了。因此NewReno出现了，它在Reno快速恢复的基础上稍加了修改，可以恢复一个窗口内多个包丢失的情况。具体来讲就是：Reno在收到一个新的数据的ACK时就退出了快速恢复状态了，而NewReno需要收到该窗口内所有数据包的确认后才会退出快速恢复状态，从而更一步提高吞吐量。

SACK就是改变TCP的确认机制，最初的TCP只确认当前已连续收到的数据，SACK则把乱序等信息会全部告诉对方，从而减少数据发送方重传的盲目性。比如说序号1，2，3，5，7的数据收到了，那么普通的ACK只会确认序列号4，而SACK会把当前的5，7已经收到的信息在SACK选项里面告知对端，从而提高性能，当使用SACK的时候，NewReno算法可以不使用，因为SACK本身携带的信息就可以使得发送方有足够的信息来知道需要重传哪些包，而不需要重传哪些包。

(5) TCP的应用

前几天和公司做防火墙限速的同事聊天, 我们公司新的防火墙限速实现方案就用到了TCP窗口机制. 作所周知, QoS除了分类，测速，队列还有调度一类的借助硬件的算法以外，在基于缓存或者丢包的限速基础上，最好还要降低TCP端到端的真正发送的速率，否则容易引起TCP的一系列拥塞控制动作。我们软件新的设计，就是通过修改ACK方向的通告窗口大小，来控制发送发的速率，能够在限速的基础上，同时降低发送方的发送速率。

本文出自“jasonccie”博客，请务必保留此出处https://www.sodocs.net/doc/c014248818.html,/2143955/422966

CycloneTCP协议栈移植与使用简介

Arda Technology Arda Tech P.F.FU 2014-12-19 Ver 0.1 #elif defined(USE_XXXXXX) #include "os_port_xxxxxx.h"

NicType type;//控制器类型。0：以太网接口，1：PPP接口，2：6LowPan接口 NicInit init;//控制器初始化函数指针 NicTick tick;//控制器周期性事务处理函数指针 NicEnableIrq enableIrq;//打开控制器中断函数指针 NicDisableIrq disableIrq;//关闭控制器中断函数指针 NicEventHandler eventHandler;//控制器中断响应函数指针，这个是下半段的中断处理部分。 NicSetMacFilter setMacFilter;//配置多播MAC地址过滤函数指针 NicSendPacket sendPacket;//发送包函数指针 NicWritePhyReg writePhyReg;//写PHY寄存器函数指针 NicReadPhyReg readPhyReg;//读PHY寄存器函数指针 bool_t autoPadding;//是否支持自动填充 bool_t autoCrcGen;//是否支持自动生成CRC校验码 bool_t autoCrcCheck;//是否支持自动检查CRC错误 NicSendControlFrame sendControlFrame;//发送控制帧函数指针 NicReceiveControlFrame receiveControlFrame;//接收控制帧函数指针 NicPurgeTxBuffer purgeTxBuffer;//清除发送缓冲函数指针 NicPurgeRxBuffer purgeRxBuffer;//清除接受缓存函数指针 xxxxEthInitGpio(...)//用于在init中初始化GPIO。 xxxxEthInitDmaDesc(...)//用于在init中初始化DMA任务描述符列表。 XXXX_Handler(...)//用于MAC中断的上半段处理。 xxxxEthReceivePacket(...)//用于在eventHandler中收包，把数据从dma的缓冲复制到外部缓冲。xxxxEthCalcCrc(...)//计算CRC值，这个函数基本上是固定的。 xxxxEthDumpPhyReg(...)//用于调试的打印PHY寄存器列表值。

TCPIP协议栈实践报告

《专业综合实践》 训练项目报告训练项目名称：TCP/IP协议栈

1.IP协议 IP协议是TCP/IP协议的核心，所有的TCP，UDP，IMCP，IGCP的数据都以IP数据格式传输。要注意的是，IP不是可靠的协议，这是说，IP协议没有提供一种数据未传达以后的处理机制－－这被认为是上层协议－－TCP或UDP要做的事情。所以这也就出现了TCP是一个可靠的协议，而UDP就没有那么可靠的区别。这是后话，暂且不提 1.1.IP协议头如图所示

挨个解释它是教科书的活计，我感兴趣的只是那八位的TTL字段，还记得这个字段是做什么的么？这个字段规定该数据包在穿过多少个路由之后才会被抛弃(这里就体现出来IP协议包的不可靠性，它不保证数据被送达)，某个ip数据包每穿过一个路由器，该数据包的TTL数值就会减少1，当该数据包的TTL成为零，它就会被自动抛弃。这个字段的最大值也就是255，也就是说一个协议包也就在路由器里面穿行255次就会被抛弃了，根据系统的不同，这个数字也不一样，一般是32或者是64，Tracerouter这个工具就是用这个原理工作的，tranceroute 的-m选项要求最大值是255，也就是因为这个TTL在IP协议里面只有8bit。 现在的ip版本号是4，所以也称作IPv4。现在还有IPv6，而且运用也越来越广泛了。 1.2.IP路由选择 当一个IP数据包准备好了的时候，IP数据包（或者说是路由器）是如何将数据包送到目的地的呢？它是怎么选择一个合适的路径来"送货"的呢？ 最特殊的情况是目的主机和主机直连，那么主机根本不用寻找路由，直接把数据传递过去就可以了。至于是怎么直接传递的，这就要靠ARP协议了，后面会讲到。 稍微一般一点的情况是，主机通过若干个路由器(router)和目的主机连接。那么路由器就要通过ip包的信息来为ip包寻找到一个合适的目标来进行传递，比如合适的主机，或者合适的路由。路由器或者主机将会用如下的方式来处理某一个IP数据包 如果IP数据包的TTL（生命周期）以到，则该IP数据包就被抛弃。 搜索路由表，优先搜索匹配主机，如果能找到和IP地址完全一致的目标

mtcp协议栈

mTCP:A Highly Scalable User-level TCP Stack for Multicore Systems EunYoung Jeong,Shinae Woo,Muhammad Jamshed,Haewon Jeong Sunghwan Ihm*,Dongsu Han,and KyoungSoo Park KAIST*Princeton University Abstract Scaling the performance of short TCP connections on multicore systems is fundamentally challenging.Although many proposals have attempted to address various short-comings,inef?ciency of the kernel implementation still persists.For example,even state-of-the-art designs spend 70%to80%of CPU cycles in handling TCP connections in the kernel,leaving only small room for innovation in the user-level program. This work presents mTCP,a high-performance user-level TCP stack for multicore systems.mTCP addresses the inef?ciencies from the ground up—from packet I/O and TCP connection management to the application inter-face.In addition to adopting well-known techniques,our design(1)translates multiple expensive system calls into a single shared memory reference,(2)allows ef?cient?ow-level event aggregation,and(3)performs batched packet I/O for high I/O ef?ciency.Our evaluations on an8-core machine showed that mTCP improves the performance of small message transactions by a factor of25compared to the latest Linux TCP stack and a factor of3compared to the best-performing research system known so far.It also improves the performance of various popular applications by33%to320%compared to those on the Linux stack. 1Introduction Short TCP connections are becoming widespread.While large content transfers(e.g.,high-resolution videos)con-sume the most bandwidth,short“transactions”1dominate the number of TCP?ows.In a large cellular network,for example,over90%of TCP?ows are smaller than32KB and more than half are less than4KB[45]. Scaling the processing speed of these short connec-tions is important not only for popular user-facing on-line services[1,2,18]that process small messages.It is 1We refer to a request-response pair as a transaction.These transac-tions are typically small in size.also critical for backend systems(e.g.,memcached clus-ters[36])and middleboxes(e.g.,SSL proxies[32]and redundancy elimination[31])that must process TCP con-nections at high speed.Despite recent advances in soft-ware packet processing[4,7,21,27,39],supporting high TCP transaction rates remains very challenging.For exam-ple,Linux TCP transaction rates peak at about0.3million transactions per second(shown in Section5),whereas packet I/O can scale up to tens of millions packets per second[4,27,39]. Prior studies attribute the inef?ciency to either the high system call overhead of the operating system[28,40,43] or inef?cient implementations that cause resource con-tention on multicore systems[37].The former approach drastically changes the I/O abstraction(e.g.,socket API) to amortize the cost of system calls.The practical lim-itation of such an approach,however,is that it requires signi?cant modi?cations within the kernel and forces ex-isting applications to be re-written.The latter one typically makes incremental changes in existing implementations and,thus,falls short in fully addressing the inef?ciencies. In this paper,we explore an alternative approach that de-livers high performance without requiring drastic changes to the existing code base.In particular,we take a clean-slate approach to assess the performance of an untethered design that divorces the limitation of the kernel implemen-tation.To this end,we build a user-level TCP stack from the ground up by leveraging high-performance packet I/O libraries that allow applications to directly access the packets.Our user-level stack,mTCP,is designed for three explicit goals: 1.Multicore scalability of the TCP stack. 2.Ease of use(i.e.,application portability to mTCP). 3.Ease of deployment(i.e.,no kernel modi?cations). Implementing TCP in the user level provides many opportunities.In particular,it can eliminate the expen-sive system call overhead by translating syscalls into inter-process communication(IPC).However,it also in-

tcp、ip协议栈移植

This article was downloaded by: [University of Jiangnan] On: 27 March 2015, At: 06:51 Publisher: Taylor & Francis Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK Journal of Discrete Mathematical Sciences and Cryptography Publication details, including instructions for authors and subscription information: https://www.sodocs.net/doc/c014248818.html,/loi/tdmc20 An abridged protocol stack for micro controller in place of TCP/IP R. Seshadri a a Computer Centre, S.V. University , Tirupati , 517 502 , India Published online: 03 Jun 2013. PLEASE SCROLL DOWN FOR ARTICLE

An abridged protocol stack for micro controller in place of TCP/IP R.Seshadri ? Computer Centre S.V .University Tirupati 517502India Abstract The existing TCP/IP protocol stack running in hosts takes lot of overhead while the node in network is for a speci?c purpose.For example transferring simple messages across network.If the node in the network is not a PC but,some thing like a micro controller,which measures some values and stores in its local memory,then it becomes lavishness in using the micro controller’s memory.As it is a node in a network,working with TCP/IP ,it should be able to transfer those values in the form of messages to other hosts which are in either local network or global network. But in micro controller terms the memory is expensive and compact.The existing TCP/IP stack consumes a few mega bytes of memory.Therefore it can’t be accommodated in the memory of micro controller.Hence one needs to reduce the memory consumption.In this regard,an abridged protocol which replaces the existing TCP/IP has been designed to suit the above needs.For this purpose,the TCP/IP have been combined with KEIL C51features for 8051micro controller to make it work in transferring messages in local area network as well as global network. The above scheme was implemented and tested and the system was working satisfac-torily.The results are found to be more effective in communicating information/message from the micro controller to a PC. Keywords :Ethernet,stack,Transmission Control Protocol (TCP ),Internet Protocol (IP ).Introduction to TCP/IP The name TCP/IP refers to a suite of communication protocols.The name is misleading because TCP and IP are the only two of the dozens of protocols that compose the suite.Its name comes from two of the most ?E-mail :ravalaseshadri@yahoo.co.in —————————————————– Journal of Discrete Mathematical Sciences &Cryptography Vol.9(2006),No.3,pp.523–536 c Taru Publications D o w n l o a d e d b y [U n i v e r s i t y o f J i a n g n a n ] a t 06:51 27 M a r c h 2015

TCPIP协议栈

TCP/IP协议族 IPv4包 UDP包 UDP的伪首部（根据IP数据包的内容建立） UDP校验和覆盖的内容超出了UDP数据报本身的X围。计算校验和，先把零值赋予校验和字段，然后对整个对象，包括伪首部、UDP的首部和用户数据，算出一个16比特的二进制

TCP包 TCP的伪首部（根据IP数据包的内容建立） 三次握手报文序列 在网点1的事件网络报文在网点2的事件 发送SYN seq=x 接收SYN报文段 发送SYN seq=y，ACK x+1

接收SYN+ACK报文段 发送ACK y+1 接收ACK报文段 TCP连接关闭的三次握手 在网点1的事件网络报文在网点2的事件 （应用程序关闭连接） 发送FIN seq=x 接收FIN报文段 发送ACK x+1 接收ACK报文段 发送FIN seq=y，ACK x+1 接收FIN+ACK报文段 发送ACK y+1 接收ACK报文段 IPv6 IPv6是“Internet Protocol Version 6”的缩写，它是IETF设计的用于替代现行版本IP协议-IPv4-的下一代IP协议。IPv6采用了分级地址模式、高效IPXX、服务质量、主机地址自动配置、认证和加密等许多技术。

IPv4和IPv6的主要差别 IPv6包结构 IPv6包由IPv6XX、扩展XX和上层协议数据单元三部分组成:

IPv6XX Version(4bit) Traffic Class(8bit) Flow Label(20bit) Payload Length(16bit) Next Header(8bit) Hop Limit(8bit) Source IP address (128bit) Destination IP address (128bit) 附：常用的Next Header 字段值表 扩展头 一个典型的IPv6包，没有扩展头。仅当需要路由器或目的节点做某些特殊处理时，才由发送方添加一个或多个扩展头。与IPv4不同，IPv6扩展头长度任意，不受40字节限制，但是为了提高处理选项头和传输层协议的性能，扩展头总是8字节长度的整数倍。 目前，RFC 2460中定义了以下6个IPv6扩展头： 1）Hop-by-Hop选项XX 包含分组传送过程中，每个路由器都必须检查和处理的特殊参数选项。Hop-by-Hop选 项XX中的选项描述一个分组的某些特性或用于提供填充。这些选项有： Pad1选项（选项类型为0），填充单字节。

TCPIP协议栈实践报告

《专业综合实践》 训练项目报告 训练项目名称：TCP/I P 协议栈 1、IP 协议 IP 协议就是TCP/IP 协议得核心,所有得TCRUDPJMCP, I GCP 得数据都 以IP 数据格式传输。要注意得就是，IP 不就是可靠得协议，这就是说，I P 协议 没有提供一种数据未传达以后得处理机制一一这被认为就是上层协议一一TCP 或UDP 要做得事情。所以这也就出现了 TCP 就是一个可靠得协议，而UDP 就 没有那么可靠得区别。这就是后话，暂且不提 1、1、IP 协议头如图所示 挨个解释它就是教科书得活计，我感兴趣得只就是那八位得TT L 字段，还记 得这个字段就是做什么得么？这个字段规定该数据包在穿过多少个路山之后才 会被抛弃（这里就体现出来I P 协议包得不可靠性，它不保证数据被送达），某个 ip 数据包每穿过一个路III 器，该数据包得TTL 数值就会减少1,当该数据包得T TL 成为零，它就会被自动抛弃。这个字段得最大值也就就是2 5 5,也就就是说 一个协议包也就在路由器里面穿行2 55次就会被抛弃了，根据系统得不同，这个 数字也不一样，一般就是32或者就是64, T r acero ute r 这个工具就就是用这个 原理丄作得，trancer o ute 得-m 选项要求最大值就是25 5，也就就是因为这个T TL 在IP 协议里面只有8b i to 现在得ip 版本号就是4,所以也称作IPv 4。现在还有IPv 6 ,而且运用也 越来越广泛了。 1、2、IP 路由选择 当一个IP 数据包准备好了得时候,IP 数据包（或者说就是路111器）就是如何 将数据包送到LI 得地得呢?它就是怎么选择一个合适得路径来”送货“得呢？ 最特殊得情况就是U 得主机与主机直连,那么主机根本不用寻找路山，直接 把数 ii 恤如紀伯 字方

嵌入式TCPIP协议栈

嵌入式TCPIP协议栈 嵌入式TCP/IP协议栈 目前，市场上几乎所有的嵌入式TCP/IP协议栈都是根据BSD版的TCP/IP协议栈改写的。在商业嵌入式TCP/IP协议栈大都相当昂贵的情况下，很多人转而使用一些源代码公开的免费协议栈，并加以改造应用。目前较为著名的免费协议栈有： lwIP(Light weight TCP/IP Stack)——支持的协议比较完整，一般需要多任务环境支持，代码占用ROM>40KB，不适合8位机系统，没有完整的应用文档； uC/IP(TCP/IP stack for uC/OS)—基于uC/OS的任务管理，接口较复杂，没有说明文档。 笔者采用的协议栈系瑞典计算机科学研究所Adam Dunkels开发的uIP0.9。其功能特性总结如下： *完整的说明文档和公开的源代码（全部用C语言编写，并附有详细注释）； *极少的代码占用量和RAM资源要求，尤其适用于8/16位单片机（见表1）； *高度可配置性，以适应不同资源条件和应用场合； *支持ARP、IP、ICMP、TCP、UDP（可选）等必要的功能特性； *支持多个主动连接和被动连接并发，支持连接的动态分配和释放； *简易的应用层接口和设备驱动层接口； *完善的示例程序和应用协议实现范例。 表1 uIP在ATMEL AVR上代码和RAM占用情况 协议模块代码大小/B 使用的RAM/B ARP 1324 118 IP/ICMP/TCP 3304 360 HTTP 994 110 校验和函数636 0 数据包缓存0 400 总和6258 988

注：配置为1个TCP听端口，10个连接，10个ARP表项，400字节数据包缓存。 正是由于uIP所具有的显著特点，自从0.6版本以来就被移植到多种处理器上，包括MSP430、AVR和Z80等。笔者使用的uIP0.9是2003年11月发布的版本。目前，笔者已将它成功移植到MCS-51上了。 2 uIP0.9的体系结构 uIP0.9是一个适用于8/16位机上的小型嵌入式TCP/IP协议栈，简单易用，资源占用少是它的设计特点。它去掉了许多全功能协议栈中不常用的功能，而保留网络通信所必要的协议机制。其设计重点放在IP、ICMP和TCP协议的实现上，将这三个模块合为一个有机的整体，而将UDP和ARP协议实现作为可选模块。UIP0.9的体系结构如图1所示。 UIP0.9处于网络通信的中间层，其上层协议在这里被称之为应用程序，而下层硬件或固件被称之为网络设备驱动。显然，uIP0.9并不是仅仅针对以太网设计的，以具有媒体无关性。 为了节省资源占用，简化应用接口，uIP0.9在内部实现上作了特殊的处理。 ①注意各模块的融合，减少处理函数的个数和调用次数，提高代码复用率，以减少ROM占用。 ②基于单一全局数组的收发数据缓冲区，不支持内存动态分配，由应用负责处理收发的数据。 ③基于事件驱动的应用程序接口，各并发连接采用轮循处理，仅当网络事件发生时 ，由uIP内核唤起应用程序处理。这样，uIP用户只须关注特定应用就可以了。传统的TCP/IP实现一般要基于多任务处理环境，而大多数8位机系统不具备这个条件。 ④应用程序主动参与部分协议栈功能的实现（如TCP的重发机制，数据包分段和流量控制），由uIP内核设置重发事件，应用程序重新生成数据提交发送，免去了大量内部缓存的占用。基于事件驱动的应用接口使得这些实现较为简单。 3 uIP的设备驱动程序接口 uIP内核中有两个函数直接需要底层设备驱动程序的支持。 一是uip_input()。当设置驱动程序从网络层收到的一个数据包时要调用这个函数，

linux tcpip协议栈分析

sk_buff结构可能是linux网络代码中最重要的数据结构，它表示接收或发送数据包的包头信息。它在 中定义，并包含很多成员变量供网络代码中的各子系统使用。 这个结构在linux内核的发展过程中改动过很多次，或者是增加新的选项，或者是重新组织已存在的成员变量以使得成员变量的布局更加清晰。它的成员变量可以大致分为以下几类： ?Layout 布局 ?General 通用 ?Feature-specific功能相关 ?Management functions管理函数 这个结构被不同的网络层（MAC或者其他二层链路协议，三层的IP，四层的TCP或UDP等）使用，并且其中的成员变量在结构从一层向另一层传递时改变。L4向L3传递前会添加一个L4的头部，同样，L3向L2传递前，会添加一个L3的头部。添加头部比在不同层之间拷贝数据的效率更高。由于在缓冲区的头部添加数据意味着要修改指向缓冲区的指针，这是个复杂的操作，所以内核提供了一个函数skb_reserve （在后面的章节中描述）来完成这个功能。协议栈中的每一层在往下一层传递缓冲区前，第一件事就是调用skb_reserve在缓冲区的头部给协议头预留一定的空间。 skb_reserve同样被设备驱动使用来对齐接收到包的包头。如果缓冲区向上层协议传递，旧的协议层的头部信息就没什么用了。例如，L2的头部只有在网络驱动处理L2的协议时有用，L3是不会关心它的信息的。但是，内核并没有把L2的头部从缓冲区中删除，而是把有效荷载的指针指向L3的头部，这样做，可以节省CPU时间。 1. 网络参数和内核数据结构 就像你在浏览TCP/IP规范或者配置内核时所看到的一样，网络代码提供了很多有用的功能，但是这些功能并不是必须的，比如说，防火墙，多播，还有其他一些功能。大部分的功能都需要在内核数据结构中添加自己的成员变量。因此，sk_buff里面包含了很多像#ifdef这样的预编译指令。例如，在sk_buff结构的最后，你可以找到： struct sk_buff { ... ... ... #ifdef CONFIG_NET_SCHED _ _u32 tc_index; #ifdef CONFIG_NET_CLS_ACT _ _u32 tc_verd; _ _u32 tc_classid; #endif #endif } 它表明，tc_index只有在编译时定义了CONFIG_NET_SCHED符号才有效。这个符号可以通过选择特定的编译选项来定义（例如："Device Drivers Networking supportNetworking options QoS and/or

TCPIP协议栈的基本工作原理

TCP/IP协议栈的基本工作原理 TCP/IP是互联网的核心协议，也是大多数网络应用的核心协议。就前面一段时间面试中问到的TCP/IP问题，这里给出一个简单的小结。 TCP由RFC793、RFC1122、RFC1323、RFC2001、RFC2018以及RFC2581定义。 (1) TCP概述 a. TCP提供的是面向连接的全双工服务。 TCP所有的数据会匹配到由源地址，目的地址，源端口，目的端口构成的一个TCP连接之上。TCP连接是一种需要建立的资源，可以通过之后会讲到的握手机制来完成。UDP是一种基于尽力而为机制的协议，不存在UDP连接资源的建立，资源的处理往往由应用层协议代劳了。 b. TCP是提供的可靠服务。 TCP有确认机制来保证数据包的可靠到达， TCP有CRC校验机制来保证数据包的无差错性，UDP的CRC是可选的， TCP会重新排序乱序的数据包和丢弃重复的数据， TCP能够提供流量控制机制，使用滑动窗口算法， TCP能提供拥塞控制与恢复机制，存在多种TCP拥塞控制模型， TCP能协商发送的数据报文长度。 TCP报头。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TCP Header Format 对于TCP头的标记位，SYN标记只在三次握手(或四次握手)的时候的被置位，ACK标记会在

tcpip协议栈开发

竭诚为您提供优质文档/双击可除 tcpip协议栈开发 篇一：什么是tcpip协议栈？栈是什么意思？ 什么是tcp/ip协议栈？栈是什么意思？ tcp/ip协议叫做传输控制/网际协议，它是internet国际互联网络的基础。tcp/ip是网络中使用的基本的通信协议。 虽然从名字上看tcp/ip包括两个协议，传输控制协议（tcp）和网际协议（ip），但tcp/ip实际上是一组协议， 它包括上百个各种功能的协议，如：远程登录、文件传输和电子邮件等，而tcp协议和ip协议是保证数据完整传输的 两个基本的重要协议。通常说tcp/ip是internet协议族，而不单单是tcp和ip。 tcp/ip协议的基本传输单位是数据包（datagram）,tcp 协议负责把数据分成若干个数据包，并给每个数据包加上包头（就像给一封信加上信封），包头上有相应的编号，以保 证在数据接收端能将数据还原为原来的格式，ip协议在每个包头上再加上接收端主机地址，这样数据找到自己要去的地方，如果传输过程中出现数据丢失、数据失真等情况，tcp 协议会自动要求数据重新传输，并重新组包。总之，ip协议

保证数据的传输，tcp协议保证数据传输的质量。tcp/ip协议数据的传输基于tcp/ip协议的四层结构：应用层、传输层、网络层、接口层，数据在传输时每通过一层就要在数据上加个包头，其中的数据供接收端同一层协议使用，而在接收端，每经过一层要把用过的包头去掉，这样来保证传输数据的格式完全一致。 tcp/ip协议介绍 tcp/ip的通讯协议 这部分简要介绍一下tcp/ip的内部结构，为讨论与互联网有关的安全问题打下基础。tcp/ip协议组之所以流行，部分原因是因为它可以用在各种各样的信道和底层协议（例如t1和x.25、以太网以及Rs-232串行接口）之上。确切地说，tcp/ip协议是一组包括tcp协议和ip协议，udp （userdatagramprotocol）协议、icmp （internetcontrolmessageprotocol）协议和其他一些协议的协议组。 tcp/ip整体构架概述 tcp/ip协议并不完全符合osi的七层参考模型。传统的开放式系统互连参考模型，是一种通信协议的7层抽象的参考模型,其中每一层执行某一特定任务。该模型的目的是使各种硬件在相同的层次上相互通信。这7层是:物理层、数据链路层、网路层、传输层、话路层、表示层和应用层。而

TCPIP协议栈lwip的移植

TCP/IP协议栈lwip的移植 新建几个头文件 Include/lwipopts.h Include/arch/cc.h Include/arch/perf.h Include/arch/sys_arch.h 除头文件外还需要添加一个C文件：sys_arch.c。说明在doc/sys_arch.txt中。 修改netif/Ethernetif.c。

结构对齐的几个宏 对于一个结构下载下来的LWIP的通用定义如下： PACK_STRUCT_BEGIN struct icmp_echo_hdr { PACK_STRUCT_FIELD(u8_t type); PACK_STRUCT_FIELD(u8_t code); PACK_STRUCT_FIELD(u16_t chksum); PACK_STRUCT_FIELD(u16_t id); PACK_STRUCT_FIELD(u16_t seqno); } PACK_STRUCT_STRUCT; PACK_STRUCT_EN #define PACK_STRUCT_FIELD(x) 这个宏是为了字节序的转换，由于是用的小端，就不用转换了直接定义为 #define PACK_STRUCT_FIELD(x) x #define PACK_STRUCT_STRUCT #define PACK_STRUCT_BEGIN #define PACK_STRUCT_END 以上三个宏都是为了做结构体对齐用： 对于gcc的编译器在结构体后跟个关键字就ok struct ip_hdr { } ;__attribute__ ((__packed__)) 因此可以定义为 #define PACK_STRUCT_STRUCT __attribute__ ((__packed__)) #define PACK_STRUCT_BEGIN #define PACK_STRUCT_END 对于vc的编译器就郁闷了,vc做结构体对齐是这样做的 #pragma pack(1) //结构体按照1字节对齐 struct ip_hdr { } ; #pragma pack() //结构体按照编译器默认值对齐 但是VC的编译器不允许将预处理做为宏，也就是不允许这种宏替代#define PACK_STRUCT_BEGIN #pragma pack(1) 所以想靠宏替换来完成字节对齐是不行了，于是就动了大工夫做了如下处理#ifdef WIN32 #define PACK_STRUCT_STRUCT #define PACK_STRUCT_BEGIN #define PACK_STRUCT_END #else #define PACK_STRUCT_STRUCT __attribute__ ((__packed__)) #define PACK_STRUCT_BEGIN #define PACK_STRUCT_END