TCP/IP

IP协议是TCP/IP协议族的动力，它为上层协议提供无状态，无连接，不可靠的服务。

使用IP服务的上层协议(比如TCP协议)需要自己实现数据确认、超时重传等机制以达到可靠传输的目的。

 

Flags, seq, win, options描述的都是TCP头部信息，length指出该IP数据报所携带的应用程序数据的长度。

MTU是Maximum Transmission Unit的缩写。意思是网络上传送的最大数据包。

当IP数据报的长度超过帧的MTU时，它将被分片传输。以太网帧的MTU是1500字节(可通过ifconfig或netstat查看)，因此它携带的IP数据报的数据部分最多是1480字节(IP头部占用20字节)。

 

TCP协议的连接是一对一的，所以基于广播和多播(目标是多个主机地址)的应用程序不能使用TCP服务，而无连接的UDP则非常适合于广播和多播。

 

当发送端应用程序连续执行多次写操作时，TCP模块先将这些数据放入TCP发送缓冲区中。当TCP模块真正开始发送数据时，发送缓冲区中这些等待发送的数据可能被封装成一个或多个TCP报文段发出。因此TCP模块发送出的TCP报文段的个数和应用程序执行的写操作数之间没有固定的数量关系。

当接收端收到一个或多个TCP报文段后，TCP模块将他们携带的应用程序数据按照TCP报文段的序号依次放入TCP接收缓冲区中，并通知应用程序读取数据。接收端应用程序可以一次性将TCP接收缓冲区中的数据全部读出，也可以分多次读取，这取决于用户指定的应用程序读缓冲区的大小。因此，应用程序执行的读操作次数和TCP模块接收到的TCP报文段个数之间也没有固定的数量关系。

 

综上所述，发送端执行的写操作次数和接收端执行的读操作次数之间没有任何数量关系，这就是字节流的概念：应用程序对数据的发送和接收是没有边界限制的。UDP则不然，发送端应用程序每执行一次写操作，UDP模块就将其封装成一个UDP数据报并发送之。接收端必须及时针对每一个UDP数据报执行读操作(recvfrom)，否则就会丢包(这经常发生在较慢的服务器上)。并且，如果用户没有指定足够的应用程序缓冲区来读取UDP数据，则UDP数据将被截断。

 

TCP连接的一端向另一端发送携带RST标志的报文段，即复位报文段，以通知对方关闭连接或重新建立连接。三种情况：

1，访问不存在的端口

2，异常终止连接

　　TCP提供了异常终止一个连接的方法，即给对方发送一个复位报文段，一旦发送了复位报文段，发送端所有排队等待发送的数据都将被丢弃。应用程序可以使用socket选项SO_LINGER来发送复位报文段，以异常终止一个连接。

3，处理半打开连接

 

 TCP报文段所携带的应用程序数据按照长度分为两种：交互数据(telnet, ssh)和成块数据(ftp)

对于交互数据：客户端对服务器的确认报文都不携带任何数据，因为客户端用户的输入速度远远慢于客户端程序的处理速度

　　　　　　　而服务端收到客户端发来的数据并不马上就行确认，而是在一段延迟时间后查看本端是否有数据需要发给客户端，如果有，则和确认信息一起发送，服务器的这种处理方式称为延迟确认。因为服务器对客户端的请求处理很快，所以他发送确认报文的时候总是有数据一起发送。延迟确认可以减少发送TCP报文段的数量。

　　　　　　Nagle算法减少过多的少量数据报

对于成块数据：当传输大量大块数据的时候，发送方会连续发送多个TCP报文段，接收方可以一次确认所有这些报文段。(滑动窗口)

 

TCP模块为每个TCP报文段都维护一个重传定时器，该定时器在TCP报文段第一次被发送时启动。如果超时时间内未收到接收方的应答，TCP模块将重传TCP报文段并重置定时器。每次重传超时时间都增加一倍，在5次重传均失败的情况下，底层的IP和ARP开始接管，直到客户端放弃连接为止。

 

拥塞控制的四个部分：慢启动，拥塞避免，快速重传，快速恢复

/proc/sys/net/ipv4/tcp_congestion_control 机器当前所使用的拥塞控制算法

慢启动：TCP模块刚开始发送数据时并不知道网络的实际情况，需要用一种试探的方式平滑地增加CWND的大小(Congestion Window, 拥塞窗口)　　

当CWND慢慢增大超过一个阀值时，TCP拥塞控制将进入拥塞避免阶段。　　　　

发送端判断拥塞发生的依据有:

1,传输超时，或者说TCP重传定时器溢出     策略：慢启动，拥塞避免

2,接收到重复的确认报文段   策略：快速重传，快速恢复

发送端如果连续收到3个重复的确认报文段，就认为是拥塞发生了，然后启用快速重传和快速恢复算法来处理拥塞，处理完成后将恢复到拥塞避免阶段。