TCPIP协议

TCP有以下几个知识点。

备用地址

备用地址

TCP的几个要点：可靠传输、流量控制、拥塞控制、连接管理（建立和释放连接）。

也正因为这几点使得首部变得很复杂。

占4位，取值范围是0x0101 ~ 0x1111。

乘以4就是首部长度（Header Length）。所以取值范围是5 ~ 60字节，由于首部固定部分占用20字节，所以可选部分至多占用40字节（和网络层首部一样）。

为什么叫数据偏移？因为相对TCP报文向右偏移首部长度后就是数据部分。

UDP的首部中有个16位的字段记录了整个UDP报文段的长度（首部 + 数据）。

但是，TCP的首部中仅仅有个4位的字段记录了TCP报文段的首部长度，并没有字段记录TCP报文段的数据长度。

分析：UDP首部中占16位的长度字段是冗余的，纯粹是为了保证首部是32bit对齐。

TCP/UDP的数据长度，完全可以由IP数据包的首部推测出来，传输层的数据长度 = 网络层的总长度 - 网络层的首部长度 - 传输层的首部长度。

占6位，目前全为0。

与UDP一样，TCP检验和的计算内容：伪首部 + 首部 + 数据。伪首部占用12字节，仅在计算检验和时起作用，并不会传递给网络层。

备用地址

一共占6位或9位。

有些资料中，TCP首部的保留（Reserved）字段占3位，标志（Flags）字段占9位。Wireshark中也是如此。是因为标志位中的前3位是无用的，所以两种说法都不能说是错的。

备用地址

备用地址

意思：紧急。当URG=1时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送。

紧急指针存放的是长度值，表示TCP的前多少字节是需要紧急优先处理的。

意思：确认。当ACK=1时，确认号字段才有效。

意思：推。一般用在交互式网络中。PUSH标志位所表达的是发送方通知接收方传输层应该尽快的将这个报文段交给应用层。

意思：重置。当RST=1时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接。

意思：同步。当SYN=1 & ACK=0时，表明这是一个建立连接的请求。若对方同意建立连接，则回复SYN=1 & ACK=1。

请求方再发送SYN=0 & ACK=1时表明开始传输数据。这也是三次握手的流程。

意思：完成。表明数据已经发送完毕，要求释放连接。

占4字节。首先，传输的每一个字节都会有一个编号（连续的字节编号也是连续的）。

在建立连接后，序号代表这一次传给对方的TCP数据部分的第一个字节的编号。

占4字节。在建立连接后，确认号代表期望对方下一次传过来的TCP数据部分的第一个字节的编号。

占2字节。这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（字节为单位）。

ARQ(Automatic Repeat-reQuest), 自动重传请求。

备用地址

无差错情况

A发送数据M1到B，B收到数据M1后向A发送确认信号M1；

A收到确认信号M1后，继续向B发送数据M2，B接收后向A发送确认信号M2。

超时重传

A发送数据M1到B，A在发送数据途中丢包或B发现数据M1有错误直接丢掉，导致B无法向A发送确认信号M1；

A在一定时间间隔后发现没有收到B发送的确认信号M1，A会继续向B发送数据M1；

B收到数据M1后向A发送确认信号M1，A收到确认信号M1后，继续向B发送M2数据。

通过确认与超时重传机制实现可靠传输，在发送完一个分组后，必须暂时保留已发送的分组的副本。

分组和确认分组都必须进行编号。超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

备用地址

确认丢失

A发送数据M1到B，B接收到数据M1后，向A发送确认信号M1；

B在向A发送确认信号M1中途丢包，此时A在一定时间间隔后发现没有收到B发送的确认信号M1，A会继续向B发送数据M1；

B收到数据M1后会丢弃重复的数据M1（之前已经收到数据M1，只是A不知道），继续向A发送确认信号M1；

A收到确认信号M1后，继续开始发送M2数据。

确认迟到

A发送数据M1到B，B接收到数据M1后，向A发送确认信号M1；

B在向A发送确认信号M1时，由于网络延迟等原因导致A在一定时间段内未收到确认信号；

A会继续向B发送数据M1，B收到数据M1后丢弃重复的数据M1，并向A发送确认信号M1；

A收到确认信号M1后，继续开始发送M2数据，M2数据刚发送出去，此时A刚好接收到B在第一次发送的确认信号M1，

但由于之前已经成功接收并处理了第二次的确认信号M1，所以A在收到确认信号后什么也不做。

出现差错或丢失的时候，发送方会将自己备份的副本再重传一次，直到收到接收的确认信息。

当接收方收到重复的数据时，会直接丢弃，但是会给发送方请确认自己已经收到了。

上面的停止等待协议每发送一组数据就必须等到接收方回复确认后，再发起第二组数据，如果出现超时重传的话，效率更低。

因此为了提高传输的效率，改进了等待传输协议。

连续ARQ协议和滑动窗口协议的机制是以接收方回复确认为单位，每次连续发送一个滑动窗口指定的数据组。

备用地址

A发送数据给B时，一次性发送M1~M4（A和B建立连接时，B告诉A自己的缓存池可以容纳多少字节数据，

A根据这个缓存池的大小构建一个同大小的发送窗口–也可以理解为发送缓存池），此时A开始等待确认，B收到全部数据后会向A发送确认信号M4（以最后一个编号为准）；

A收到确认信号后，继续向B发送M5 M8（A把之前构建的窗口滑动并锁定到对应大小的数据段上，即M5 M8），以此往复直到数据传输完毕。

如果接收窗口最多能接收4个包（窗口大小），但发送方只发了2个包，接收方如何确定后面还有没有2个包？

答案：接收方会在等待一定时间后发现没有第3个包，就会返回收到2个包的确认信号给发送方。

滑动窗口是由发送方维护的类似指针的变量，在每收到一个接收方的确认消息后，

该指针向前移动并发送数据，到窗口指定大小的数据组时停下，等待接收方的确认。

备用地址

累积确认机制： 发送方不对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，

这样就表示：到这个分组为止的所有分组都已正确收到了。

优点：容易实现，即使确认丢失也不必重传。

缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。

Go-back-N（回退 N）： 为了解决上述同一窗口中数据组不能完整确认的问题，连续ARQ协议采用了回退机制。

比如说：发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。

发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做 Go-back-N（回退 N），表示需要再退回来重传已发送过的N个分组。

结论：当通信线路质量不好时，连续ARQ协议会带来负面的影响。可能还不如传统的停止等待协议。

TCP连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。

TCP的可靠传输机制用字节的序号进行控制。TCP所有的确认都是基于序号而不是基于报文段。

TCP两端的四个窗口经常处于动态变化之中。

TCP连接的往返时间RTT也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。

滑动窗口是面向字节流的，为了方便记住每个分组的序号，

现在假设有一个1200字节的数据，分12组，每一组数据是100个字节，代表一个数据段的数据（每一个数据都有自己的TCP首部），每一组给一个编号（1~12）。

备用地址

备用地址

TCP通信时，如果发送序列中间某个数据包丢失，TCP会通过重传最后确认的分组后续的分组，这样原先已经正确传输的分组也可能重复发送，降低了TCP性能。

SACK（Selective Acknowledgment，选择确认）技术 ，使TCP只重新发送丢失的包，不用发送后续所有的分组，

而且提供相应机制使接收方能告诉发送方哪些数据丢失，哪些数据已经提前收到等。

在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好。

原来首部中的“确认号字段”的用法仍然不变。只是以后在TCP报文段的首部中都增加了SACK选项，以便报告收到的不连续的字节块的边界。

备用地址

Kind：占1个字节，值为5代表这是SACK选项。

Length：占1个字节，表明SACK选项一共占用多少字节。

Left Edge：占4个字节，左边界。

Right Edge：占4个字节，右边界。

备用地址

上图的着色模块代表已接收数据，空白代表未接收数据。左右边界意思是会把未接收完毕的TCP数据包的已接收数据进行左右标记。

由于TCP的选项不能超过40个字节，去除Kind和Length占用的2个字节，还剩下38个字节给左右边界使用。

一组边界占用8个字节（左右边界各占4个字节），所以边界不能超过4组。也能够因此推断出SACK选项的最大占用字节数是4 8 + 2 = 34。

思考：超过选项边界的数据怎么办？

超过边界的数据需要重新传输，但这已经很大程度提高了传输效率。

重传机制是TCP中最重要和最复杂的问题之一。TCP每发送一个报文段，就对这个报文段设置一次计时器。

只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。那么这个重传时间到底应该设置多少呢？建议跳过，有兴趣的可以去查阅相关资料。

备用地址

为什么选择在传输层就将数据分割成多个段，而不是等到网络层再分片传递给数据链路层？

-->网络层没有可靠传输协议，丢包无法只发送一个报文段，所以需要分割成多个段。

如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传

如果在传输层分段了，一旦出现数据丢失，只需要重传丢失的那些段即可

欢迎大家的意见和交流

email: li_mingxie@163com

传输层定义了主机应用程序之间端到端的连通性。传输层中最为常见的两个协议分别是传输控制协议TCP（Transmission Control Protocol）和用户数据报协议UDP（User Datagram Protocol）。

为了简化问题说明，本课程以Telnet为例描述相关技术。设备支持通过Telnet协议和Stelnet协议登录。使用Telnet，Stelnet v1协议存在安全风险，建议你使用STelnet v2登录设备。

为了简化问题说明，本课程以FTP为例来描述相关技术。设备支持通过FTP协议，TFTP以及SFTP传输文件。使用FTP，TFTP，SFTP v1协议存在风险，建议使用SFTP v2方式进行文件 *** 作。

TCP是一种面向连接的传输层协议，提供可靠的传输服务。

TCP是一种面向连接的端到端协议。TCP作为传输控制协议，可以为主机提供可靠的数据传输。TCP需要依赖网络协议为主机提供可用的传输路径。

TCP允许一个主机同事运行多个应用进程。每台主机可以拥有多个应用端口，没对端口号，源和目标IP地址的组合唯一地标识了一个会话。端口分为知名端口和动态端口。有些网络服务会使用固定的端口，这类端口称为知名端口，端口号范围为 0~1023 。

比如：FTP，>

计算机网络七层模型中，传输层有两个重要的协议：

（1）用户数据报协议UDP (User Datagram Protocol)

（2）传输控制协议TCP (Transmission Control Protocol)

UDP 在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP 报文后，不需要给出任何确认。虽然UDP 不提供可靠交付，但在某些情况下UDP 却是一种最有效的工作方式。

TCP 则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，如确认、流量控制、计时器以及连接管理等。

UDP 的主要特点是：

首部手段很简单，只有8 个字节，由四个字段组成，每个字段的长度都是两个字节。

前面已经讲过，每条TCP 连接有两个端点，TCP 连接的端点叫做套接字（socket）或插口。套接字格式如下：

套接宁socket= (IP 地址：端口号’）

每一条TCP 连接唯一地被通信两端的两个端点（即两个套接宇）所确定。即：

TCP 连接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}

3次握手链接

4次握手释放链接

断开连接请求可以由客户端发出，也可以由服务器端发出，在这里我们称A端向B端请求断开连接。

各个状态节点解释如下：

下面为了讨论问题的万便，我们仅考虑A发送数据而B 接收数据并发送确认。因此A 叫做发送方，而B 叫做接收方。

“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。像上述的这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest）。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。

滑动窗口协议比较复杂，是TCP 协议的精髓所在。这里先给出连续ARQ 协议最基本的概念，但不涉提到许多细节问题。详细的滑动窗口协议将在后面讨论。

下图表示发送方维持的发送窗口，它的意义是：位于发送窗口内的5 个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。

连续ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

接收方一般都是采用 累积确认 的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都己正确收到了。

累积确认 的优点是容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方己经正确收到的所有分组的信息。

例如，如果发送方发送了前5 个分组，而中间的第3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N （回退N ），表示需要再退回来重传己发送过的N 个分组。可见当通信线路质量不好时，连续ARQ 协议会带来负面的影响。

TCP 的滑动窗口是以字节为单位的。现假定A 收到了B 发来的确认报文段，其中窗口是20 （字节），而确认号是31 （这表明B 期望收到的下一个序号是31 ，而序号30 为止的数据己经收到了）。根据这两个数据， A 就构造出自己的发送窗口，其位置如图所示。

发送窗口表示：在没有收到B 的确认的情况下， A可以连续把窗口内的数据都发送出去。凡是己经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。

发送窗口后沿的后面部分表示己发送且己收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。

现在假定A 发送了序号为31 ～ 41 的数据。这时发送窗口位置并未改变，但发送窗口内靠后面有11个字节（灰色小方框表示）表示己发送但未收到确认。而发送窗口内靠前面的9 个字节（ 42 ～ 50 ）是允许发送但尚未发送的。

再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 号为止的数据是已经发送过确认，并且己经交付给主机了。因此在B 可以不再保留这些数据。接收窗口内的序号（31～50）足允许接收的。B 收到了序号为32 和33 的数据，这些数据没有按序到达，因为序号为31 的数据没有收到（也许丢失了，也许滞留在网络中的某处）。 请注意， B 只能对按序收到的数据中的最高序号给出确认，因此B 发送的确认报文段中的确认号仍然是31 （即期望收到的序号）。

现在假定B 收到了序号为31 的数据，并把序号为31～33的数据交付给主机，然后B删除这些数据。接着把接收窗口向前移动3个序号，同时给A 发送确认，其中窗口值仍为20，但确认号是34，这表明B 已经收到了到序号33 为止的数据。我们注意到，B还收到了序号为37, 38 和40 的数据，但这些都没有按序到达，只能先存在接收窗口。A收到B的确认后，就可以把发送窗口向前滑动3个序号，指针P2 不动。可以看出，现在A 的可用窗口增大了，可发送的序号范围是42～53。整个过程如下图：

A 在继续发送完序号42-53的数据后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没有再收到确认。由于A 的发送窗口己满，可用窗口己减小到0，因此必须停止发送。

上面已经讲到， TCP 的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是TCP 最复杂的问题之一。

TCP采用了一种自适应算法 ，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT，TCP 保留了RTT的一个加权平均往返时间RTTs （这又称为平滑的往返时间， S 表示Smoothed 。因为进行的是加权平均，因此得出的结果更加平滑）。每当第一次测量到RTT样本时， RTTs值就取为所测量到的RTT样本值。但以后每测量到一个新的RTT样本，就按下式重新计算一次RTTs:

新的RTTs = (1 － α）×（旧的RTTs) ＋ α ×（新的RTT样本）

α 越大表示新的RTTs受新的RTT样本的影响越大。推荐的α 值为0125，用这种方法得出的加权平均往返时间RTTs 就比测量出的RTT值更加平滑。

显然，超时计时器设置的超时重传时间RTO (RetransmissionTime-Out）应略大于上面得出的加权平均往返时间RTTs。RFC 2988 建议使用下式计算RTO:

RTO = RTTs + 4 × RTTd

RTTd是RTT 的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。计算公式如下：

新的RTTd= (1- β）×（旧的RTTd) + β × |RTTs－新的RTT样本|

发现问题： 如图所示，发送出一个报文段。设定的重传时间到了，还没有收到确认。于是重

传报文段。经过了一段时间后，收到了确认报文段。现在的问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？

若收到的确认是对重传报文段的确认，但却被源主机当成是对原来的报文段的确认，则这样计算出的RTTs 和超时重传时间RTO 就会偏大。若后面再发送的报文段又是经过重传后才收到确认报文段，则按此方法得出的超时重传时间RTO 就越来越长。

若收到的确认是对原来的报文段的确认，但被当成是对重传报文段的确认，则由此计算出的RTTs 和RTO 都会偏小。这就必然导致报文段过多地重传。这样就有可能使RTO 越来越短。

Kam 提出了一个算法：在计算加权平均RTTs 时，只要报文段重传了就不采用其往返时间样本。这样得出的加权平均RTTs 和RTO 就较准确。

新问题： 设想出现这样的情况：报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Kam 算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。

解决方案： 对Kam 算法进行修正，方法是z报文段每重传一次，就把超时重传时间RTO 增大一些。典型的做法是取新的重传时间为2 倍的旧的重传时间。当不再发生报文段的重传时，才根据上面给出的公式计算超时重传时间。

流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。

利用滑动窗口机制可以很方便地在TCP 连接上实现对发送方的流量控制。

接收方的主机B 进行了三次流量控制。第一次把窗口减小到rwnd =300，第二次又减到rwnd = 100 ，最后减到rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B 重新发出一个新的窗口值为止。我们还应注意到，B 向A 发送的三个报文段都设置了ACK=1，只有在ACK=1 时确认号字段才有意义。

发生死锁： 现在我们考虑一种情况。上图中， B 向A 发送了零窗口的报文段后不久， B 的接收缓存又有了一些存储空间。于是B 向A 发送了rwnd = 400 的报文段。然而这个报文段在传送过程中丢失了。A 一直等待收到B 发送的非零窗口的通知，而B 也一直等待A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。

解决方案： TCP 为每一个连接设有一个 持续计时器（persistence timer） 。只要TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个 零窗口探测报文段 （仅携带1 宇节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

1 TCP连接时是三次握手，那么两次握手可行吗？

在《计算机网络》中是这样解释的：已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ACK包。这样就会白白浪费资源。而经过三次握手，客户端和服务器都有应有答，这样可以确保TCP正确连接。

2 为什么TCP连接是三次，挥手确是四次？

在TCP连接中，服务器端的SYN和ACK向客户端发送是一次性发送的，而在断开连接的过程中，B端向A端发送的ACK和FIN是是分两次发送的。因为在B端接收到A端的FIN后，B端可能还有数据要传输，所以先发送ACK，等B端处理完自己的事情后就可以发送FIN断开连接了。

3 为什么在第四次挥手后会有2个MSL的延时？

MSL是Maximum Segment Lifetime，最大报文段生存时间，2个MSL是报文段发送和接收的最长时间。假定网络不可靠，那么第四次发送的ACK可能丢失，即B端无法收到这个ACK，如果B端收不到这个确认ACK，B端会定时向A端重复发送FIN，直到B端收到A的确认ACK。所以这个2MSL就是用来处理这个可能丢失的ACK的。

1 文件传送协议

文件传送协议FTP (File Transfer Protocol) [RFC 959］是因特网上使用得最广泛的文件传送协议，底层采用TCP协议。

盯P 使用客户服务器方式。一个FTP 服务器进程可同时为多个客户进程提供服务。FTP的服务器进程由两大部分组成：一个主进程，负责接受新的请求：另外有若干个从属进程，负责处理单个请求。

在进行文件传输时，客户和服务器之间要建立两个并行的TCP 连接：“控制连接”（21端口）和“数据连接”（22端口）。控制连接在整个会话期间一直保持打开， FTP 客户所发出的传送请求，通过控制连接发送给服务器端的控制进程，但控制连接并不用来传送文件。实际用于传输文件的是“数据连接”。服务器端的控制进程在接收到FTP 客户发送来的文件传输请求后就创建“数据传送进程”和“数据连接”，用来连接客户端和服务器端的数据传送进程。

2 简单文件传送协议TFTP

TCP/IP 协议族中还有一个简单文件传送协议TFfP (Trivial File Transfer Protocol），它是一个很小且易于实现的文件传送协议，端口号69。

TFfP 也使用客户服务器方式，但它使用UDP 数据报，因此TFfP 需要有自己的差错改正措施。TFfP 只支持文件传输而不支持交耳。

3 TELNET

TELNET 是一个简单的远程终端协议，底层采用TCP协议。TELNET 也使用客户服务器方式。在本地系统运行TELNET 客户进程，而在远地主机则运行TELNET 服务器进程，占用端口23。

4 邮件传输协议

一个电子邮件系统应具如图所示的三个主要组成构件，这就是用户代理、邮件服务器，以及邮件发送协议（如SMTP ）和邮件读取协议（如POP3)， POP3 是邮局协议（Post Office Protocol）的版本3 。

SMTP 和POP3 （或IMAP ）都是在TCP 连接的上面传送邮件，使用TCP 的目的是为了使邮件的传送成为可靠的。

unix的哲学是一切皆文件，可以把socket看成是一种特殊的文件，而一些socket函数就是对其进行的 *** 作api（读/写IO、打开、关闭）。我们知道普通文件的打开 *** 作（open）返回一个文件描述字，与之类似，socket()用于创建一个socket描述符（socket descriptor），它唯一标识一个socket。

当我们调用socket创建一个socket时，返回的socket描述字它存在于协议族（address family，AF_XXX）空间中，但没有一个具体的地址。如果想要给它赋值一个地址，就必须调用bind()函数，

 sockfd即socket描述字，它是通过socket()函数创建了，唯一标识一个socket。bind()函数就是将给这个描述字绑定一个名字。

    在将一个地址绑定到socket的时候，需要先将主机字节序转换成为网络字节序，而不要假定主机字节序跟网络字节序一样使用的是Big-Endian。由于这个问题曾引发过不少血案，谨记对主机字节序不要做任何假定，务必将其转化为网络字节序再赋给socket。

    这里的主机字节序就是我们平常说的大端和小端模式：不同的CPU有不同的字节序类型，这些字节序是指整数在内存中保存的顺序，这个叫做主机序。引用标准的Big-Endian和Little-Endian的定义如下：

   listen函数的第一个参数即为要监听的socket描述字，第二个参数为socket可以接受的排队的最大连接个数。listen函数表示等待客户的连接请求。

  connect函数的第一个参数即为客户端的socket描述字，第二参数为服务器的socket地址，第三个参数为socket地址的长度。客户端通过调用connect函数来建立与TCP服务器的连接。

 TCP服务器端依次调用socket()、bind()、listen()之后，就会监听指定的socket地址了。TCP客户端依次调用socket()、connect()之后就向TCP服务器发送连接请求。TCP服务器监听到这个请求之后，就会调用accept()函数去接收请求，这样连接就建立好了(在connect之后就建立好了三次连接)，之后就可以开始进行类似于普通文件的网络I/O *** 作了。

 如果accpet成功，那么其返回值是由内核自动生成的一个全新的描述字，代表与客户的TCP连接。

 accept的第一个参数为服务器的socket描述字，是服务器开始调用socket()函数生成的，称为监听socket描述字；而accept函数返回的是已连接的socket描述字。一个服务器通常通常仅仅只创建一个监听socket描述字，它在该服务器的生命周期内一直存在。内核为每个由服务器进程接受的客户连接创建了一个已连接socket描述字，当服务器完成了对某个客户的服务，相应的已连接socket描述字就被关闭。

 read函数是负责从fd中读取内容当读成功时，read返回实际所读的字节数，如果返回的值是0表示已经读到文件的结束了，小于0表示出现了错误。如果错误为EINTR说明读是由中断引起的，如果是ECONNREST表示网络连接出了问题。

 write函数将buf中的nbytes字节内容写入文件描述符fd成功时返回写的字节数。失败时返回-1，并设置errno变量。 在网络程序中，当我们向套接字文件描述符写时有俩种可能。1)write的返回值大于0，表示写了部分或者是全部的数据。2)返回的值小于0，此时出现了错误

 在服务器与客户端建立连接之后，会进行一些读写 *** 作，完成了读写 *** 作就要关闭相应的socket描述字，类似于 *** 作完打开的文件要调用fclose关闭打开的文件。

 close一个TCP socket的缺省行为时把该socket标记为已关闭，然后立即返回到调用进程。该描述字不能再由调用进程使用，也就是说不能再作为read或write的第一个参数

 close *** 作只是使相应socket描述字的引用计数-1，只有当引用计数为0的时候，才会触发TCP客户端向服务器发送终止连接请求。

 我们知道tcp建立连接要进行“三次握手”，即交换三个分组。大致流程如下：

客户端向服务器发送一个SYN J

服务器向客户端响应一个SYN K，并对SYN J进行确认ACK J+1

客户端再想服务器发一个确认ACK K+1

socket中TCP的四次握手释放连接详解

 某个应用进程首先调用close主动关闭连接，这时TCP发送一个FIN M；另一端接收到FIN M之后，执行被动关闭，对这个FIN进行确认。一段时间之后，服务端调用close关闭它的socket。这导致它的TCP也发送一个FIN N；接收到这个FIN的源发送端TCP对它进行确认,这样每个方向上都有一个FIN和ACK。

为什么要三次握手

由于tcp连接是全双工的，存在着双向的读写通道，每个方向都必须单独进行关闭。当一方完成它的数据发送任务后就可以发送一个FIN来终止这个方向的连接。收到FIN只意味着这个方向上没有数据流动，但并不表示在另一个方向上没有读写，所以要双向的读写关闭需要四次握手，

    3 time_wait状态如何避免？

首先服务器可以设置SO_REUSEADDR套接字选项来通知内核，如果端口忙，但TCP连接位于TIME_WAIT状态时可以重用端口。在一个非常有用的场景就是，如果你的服务器程序停止后想立即重启，而新的套接字依旧希望使用同一端口，此时SO_REUSEADDR选项就可以避免TIME_WAIT状态。

1客户端连接服务器的80服务，这时客户端会启用一个本地的端口访问服务器的80，访问完成后关闭此连接，立刻再次访问服务器的

80，这时客户端会启用另一个本地的端口，而不是刚才使用的那个本地端口。原因就是刚才的那个连接还处于TIME_WAIT状态。

2客户端连接服务器的80服务，这时服务器关闭80端口，立即再次重启80端口的服务，这时可能不会成功启动，原因也是服务器的连

接还处于TIME_WAIT状态。

实战分析：

状态描述：

CLOSED：无连接是活动的或正在进行

LISTEN：服务器在等待进入呼叫

SYN_RECV：一个连接请求已经到达，等待确认

SYN_SENT：应用已经开始，打开一个连接

ESTABLISHED：正常数据传输状态

FIN_WAIT1：应用说它已经完成

FIN_WAIT2：另一边已同意释放

ITMED_WAIT：等待所有分组死掉

CLOSING：两边同时尝试关闭

TIME_WAIT：另一边已初始化一个释放

LAST_ACK：等待所有分组死掉</pre>

命令解释：

如何尽量处理TIMEWAIT过多

编辑内核文件/etc/sysctlconf，加入以下内容：

netipv4tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；

netipv4tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

netipv4tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

netipv4tcp_fin_timeout 修改系默认的 TIMEOUT 时间</pre>

然后执行 /sbin/sysctl -p 让参数生效

/etc/sysctlconf是一个允许改变正在运行中的Linux系统的接口，它包含一些TCP/IP堆栈和虚拟内存系统的高级选项，修改内核参数永久生效。

简单来说，就是打开系统的TIMEWAIT重用和快速回收。

  本文主要讲述了socket的主要api，以及tcp的连接过程和其中各个阶段的连接状态，理解这些是更深入了解tcp的基础！

当ACK=1时，确认字段才有效。

当ACK=0时，确认号无效。

TCP规定，在连接建立后所有传送的报文段都必须把ACK置1。

TCP报文段分为首部和数据两部分。

TCP报文段首部的前20个字节是固定的，后面有4N字节是根据需要而增加的选项（N是整数）。因此TCP首部的最小长度是20字节。

以上就是关于TCP/IP协议全部的内容，包括:TCP/IP协议、tcp的报文包括两部分,分别是( )。、【网络协议笔记】第四层:传输层(Transport)TCP协议简介(1)等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！