豌豆

TCP 协议错综复杂， 很容易出现错误，错误码非常之多。这里探究一些在编程中比较常见的错误码。tcp 错误码 在不同的操作系统中的值不同。这里取用 Linux 与 Windows 两种，如 connection_refused 在windows  中的值为10054， 在 Linux 中为54 .

eof :

• 2 : End of file

eof 标志着流的结束。当对端关闭连接(调用了 shutdown 或 close) 后，处于 CLOSE_WAIT 状态。 本端会收到 FIN, ACK 。此时如果本端再试图 read ，则会读到 eof

connection_refused

• 61 : Connection refused
• 10061 : No connection could be made because the target machine actively refused it . 由于目标计算机积极拒绝，无法连接

在客户端试图与服务端建立连接的时候发生。一般是服务端没有处于监听状态。 客户端发送发 SYN ， 但是收到了 RST, ACK

connection_reset

• 54 : Connection reset by peer
• 10054 : An existing connection was forcibly closed by the remote host . 远程主机强迫关闭了一个现有的连接。

对端对处于连接状态的socket 进行了异常断开， 如进程中断等。此时如果本端进行读操作，可能会得到此错误。 继续阅读

最近一段时间在解决一个网络方面的 BUG,发现自己对 TCP 的状态了解得不够，于是复习了一遍 TCP 的各种状态与状态间的转换，并做了一个整理，以加深自己的理解。

网络上的两台设备想要一起工作，就必须使用相同的网络协议。像 TCP 这种复杂的协议，我们很难简洁地描述其各种确切的操作。所以我们试图使用有限状态机来解释这个复杂的协议。

一. 有限状态机

有限状态机 (FSM : Finite State Machine) 又称有限状态自动机，简称状态机，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。FSM 的四个基本概念如下：

1. 状态 state: 描述机器在特定时间上处于的 环境(circumstance)或状况(status)
2. 转换 Transition: 从一种状态到另一种状态的行为(act)
3. 事件 Event: 导致状态发生变化的事情
4. 动作 Action: 机器从一种状态转换之前对事件所做的响应

FSM通过解释协议可以处于的所有不同状态、可以在每个状态中发生的事件、针对事件采取的操作以及结果发生的转换来描述协议。协议通常在第一次运行时以特定的开始状态启动。尔后，它遵循一系列步骤使其进入常规操作状态，并根据特定类型的输入或其他情况移动到其他状态。状态机之所以称为有限状态机，是因为只有有限数量的状态。

二. TCP 的操作与状态

对于 TCP 来说，可以使用 FSM 来描述一个连接的生命周期 : 一个 TCP 设备和另一个 TCP 设备之间的每个连接，都从一个空状态(null state) 开始，经过一系列的状态变化，直到建立了(established)连接。然后它将保持这种状态，直到遇到某种事件，它将进行一系列状态直到回到关闭状态。
我们使用三个缩写词来表示状态间转换的三种类型消息，它们对应于 TCP 头的标志。(关于 TCP 头的内容可以参见我之前的博客 《TCP 协议概述》) ：

继续阅读

TCP(TRANSMISSION CONTROL PROTOCOL，即传输控制协议)

是当今网络中使用得最为广泛的协议。与 UDP不同，TCP 提供了一种 面向连接(connection-oriented) 的、可靠的字节流服务。"面向连接",是指使用 TCP 的两个应用程序 必须在它们可以交换数据之前，通过相互联系建立起一个 TCP 连接。建立起连接的两端称为两个 端点(endpoint) 。因为 TCP 是面向连接的，所以像广播和组播这样的概念在 TCP 中是不存在的。 TCP 提供了流的概念，应用程序可以将任意大小的数据交给 TCP而不用关心如何发送。如，一个应用程序在一端先后写入 10 个字节、20个字节、50个字节的数据，连接的另一端的应用程序是不需要关心这个过程的，应用程序可以选择自己读取数据流的大小，如一次读20字段分4次读取，也可以一次读入80个字节。

一个 TCP 块包含了 TCP头和应用程序数据，称之为 报文段(segment) 。TCP 是依赖于 IP 协议的，TCP 必须将报文段转换成一个 IP 可以携带的分组，这被称为一个 组包(packetizition)

如图，显示了 TCP 在 IP 数据报中的封装，以及 TCP 头部的结构。其中，着色部分用于与该报文的发送方关联的相反方向上的数据流。

• 端口号 每个TCP 头包含了源和目标的端口号，这两个值与IP头部的源和目标IP地址一起组成了唯一标识。一个IP与一个端口的组合被你为一个 端点(endpoint) 或一个 套接字(Socket) ,每一个TCP连接由一对套接字唯一标识。
• 序列号 字段标识了TCP发送端到接收端的数据流的字节数，代表着该报文段的数据中的第一个字节。它是一个32位无符号数，到达 2³²-1后再循环到0. 使用序列号，TCP的接收端可以丢弃重复的报文，并归整以杂乱次序到达的报文。TCP接收到报文的顺序是不可控的，然而TCP是一种流协议，它不能向程序程序提供顺序错乱的数据，因此，TCP接收端在向上层提供数据时，会等待较小序列号的报文，并对报文进行排序。
• 确认号 可以认为，TCP 发送的数据的每一个字节都已被编号。当TCP接收到另一端发送的数据时，它会发送一个确认。但这个确认可能不会立即发出。当接收方向发送方确认接收时，确认号表示发送言期望收到的下一个报文的序列号。所以确认号应该为 序列号 + 收到的数据的字节数据 + 1 。确认号字段只有在ACK字段启用后才有效。TCP使用确认是积累的，可以认为，一个确认号 N 表示 N-1 个字节已经被成功接收。
• 头部长度 字段给出了头部的长度，以32位字为单位。该字段只有4位，那么它能表示的最大头部长度为 60 字节。((2^{4}-1) * 32 / 8)。即一个TCP报文的头部长度的范围为 20 ~ 60 字节。
• 窗口大小 字段用来控制流量。该字段以字节为单位，因为它是 16 位的，故限制了窗口大小为 65535 字节，从而限制了 TCP 的吞吐性能。
• TCP校验和 字段由发送方计算和保存，由接收方校验。它用于检测传送过程中的比特差错。如果一个报文的校验和无效，那么TCP会丢弃它而不会返回任何确认信息。然而TCP可能会对一个已经确认过的报文再次确认，以帮助发送方计算它的拥塞控制。
• 紧急指针 字段只有在URG字段设置时才有效。它表示从报文的序列号开始的一个 正偏移 ，用以产生紧急数据的字段一个字段的序列号。
• 选项 是可变的。最常见的选项是 “最大段大小” 选项(MSS)，连接的每一个端点一般在它发送的第一个报文上指定该选项(即设置SYN位字段的那个报文)，指定该选项的发送者在相反方向上希望接收到的报文段的最大值。
• 标识位
  • CWR: 拥塞窗口减(发送方降低它的发送速率)
  • ECE: ECN 回显(发送方接收到了一个更早的拥塞报告)
  • URG: 紧急(紧急指针字段有效)
  • ACK: 确认(确认号字段有效)
  • PSH: 推送(接收方应该尽快给应用程序传送这个数据 —然而没有被可靠实现或用到)
  • RST: 重置连接(连接取消，经常是因为错误)
  • SYN: 用于初始化一个连接的同步序列号
  • FIN: 结束向对方发送数据

当TCP发送一组报文段时，通常会设置一个重传计时器，等待对方确认接收。当对方的确认报文到达时，该计时器会被更新，如果确认没有及时到达，这个报文就会被重传。 TCP提供了一种可靠、面向连接、字节流、传输层的服务。在接下来，我们将对TCP的细节进行研究。

read/write 为什么会被阻塞

首先应该知道的是，当write成功返回时，只是将buf中的数据复制到了缓冲区，至于数据什么时候被发往网络，什么时候被对方主机接收，什么时候被对方进程读取，系统调用层面不会给予任何保证和通知。
当kernel的该socket的发送缓冲区已满时，write就会被阻塞。每个socket都拥有自己的send buffer和receive buffer，其大小由系统自动调节。

已经发送到网络的数据依然需会在send buffer中暂存，只有当收到对方的ack后，kernel才从buffer中将这一部分清除。接收端将收到的数据暂存在receive buffer中，自动进行确认。但如果socket所在的进程来不及时将数据从receive buffer中取出，最终导致receive buffer填满，由于TCP的滑动窗口和拥塞控制，接收端会阻止发送端向其发送数据。这些控制皆发生在TCP/IP栈中，对应用程序是透明的，应用程序继续发送数据，最终导致send buffer填满，write调用阻塞。
一般来说，由于接收端进程从socket读数据的速度跟不上发送端进程向socket写数据的速度，最终导致发送端write调用阻塞。
而read调用的行为则相对容易理解，从socket的receive buffer中拷贝数据到应用程序的buffer中。read调用阻塞，通常是发送端的数据没有到达。 继续阅读