TCP学习笔记

TCP协议与其它协议之间的关系：

       +------+ +-----+ +-----+       +-----+                    
       |Telnet| | FTP | |Voice|  ...  |     |  Application Level 
       +------+ +-----+ +-----+       +-----+                    
             |   |         |             |                       
            +-----+     +-----+       +-----+                    
            | TCP |     | RTP |  ...  |     |  Host Level        
            +-----+     +-----+       +-----+                    
               |           |             |                       
            +-------------------------------+                    
            |    Internet Protocol & ICMP   |  Gateway Level     
            +-------------------------------+                    
                           |                                     
              +---------------------------+                      
              |   Local Network Protocol  |    Network Level     
              +---------------------------+   

 

TCP的流控制是通过在接收者发往发送者的ACK中TCP首部的window字段（接收窗口长度）来实现的：

    TCP provides a means for the receiver to govern the amount of data
    sent by the sender.  This is achieved by returning a "window" with
    every ACK indicating a range of acceptable sequence numbers beyond
    the last segment successfully received.  The window indicates an
    allowed number of octets that the sender may transmit before
    receiving further permission.

TCP具有超时重发的机制，如果在指定时间内没有接收到相应的ACK，那么相应的Segment将会重新发送。

可以同时打开多个SOCKET去监听同一个PORT， 那么TCP将首先匹配到指定外部SOCKET地址的TCB，然后再去匹配不指定外部SOCKET地址的TCB。

 

icmp可以用于获取另一台机器的时间，发送端在“发送时间戳”字段填入发送的时间，而接收端需要在“接收时间戳”字段写入接收到的时间并再次发回给发送端，这样子一来发送端就可以计算出从往返延迟了。另外RFC1307还描述了一种毫秒级的时间同步协议。

 

一个连接同时使用sourceIP destIP sourcePort destPort来唯一确定 。

 

为什么TCP需要3次握手而不是2次:

第一次在面试题里面看到这个问题，根RFC793上的说法，TCP其于IP(Internet Protocol)协议，IP协议是不可靠的，建立一个100%可靠的连接显然不可能。当然，如果连接足够可靠，那我们无须进行这个过程，或者我们可以将握手的次数增加到4次或者5次以得到一个更加稳定的连接)，3次连接则是这样子的一个折中。可以避免大部分错误的情况，同时节省建立连接的消耗。

从另一个方面来说，让连接双方都相互“知道”彼此的ISN，那么至少进行3次握手，两次学习到其中一方的ISN。

因为握手过程中发送的SYN和ACK可能会迟到或者丢失，所以，在不稳定的网络环境中，两次握手是不恰当的，比如下面的过程，TCP发出ACK之后马上进入ESTABLISHED状态，并通知上层的应用程序，但步骤2中的ACK很可能会丢失。如果某个时候网络环境很糟糕，上层的应用则得到大量无效的连接，这是不恰当的。

    TCP A                                                 TCP B
    CLOSED                                                LISTEN
1: (SYN_SENT)        ---(SEQ=100,CTL=SYN) -->             (SYN_RECEIVED)
2: (ESTABLISHED)     <--(SEQ=300,ACK=101,CTL=ACK) --      (ESTABLISHED)
                          POSSIBILITY 1


    TCP A                                                 TCP B
    CLOSED                                                LISTEN
1: (SYN_SENT)       ---(SEQ=100,CTL=SYN) ...              LISTEN
2: (SYN_SENT)       ---(SEQ=110,CTL=SYN) ...              LISTEN
3:                  ---(SEQ=100,CTL=SYN) -->              (SYC_RECEIVED)
4: (ESTABLISHED)    <--(SEQ=200,ACK=101,CTL=ACK) ---      (ESTABLISHED)
5:                  ---(SEQ=110,CTL=SYN) -->              (???)
                          POSSIBILITY 2

 

一些控制packet的segment length==1

Usually, TCP packets with a len of 1 are control packets (ACK,SYN,FIN,RST)

 

TCP连接断开的过程也比较麻烦，有四次握手的说法，但这种说法可以说不是很准确。

TCP A
CLOSE_WAIT_1    ---(SEQ=300,ACK=100,CTL=<FIN,ACK>) -->    FIN_WAIT
CLOSE_WAIT_2    <--(SEQ=100,ACK=301,CTL=<ACK>)     ---    FIN_WAIT
TIME_WAIT       <--(SEQ=xxx,ACK=301,CTL=<FIN,ACK>) ---    LAST_ACK(Close)
TIME_WAIT       ---(SEQ=301,ACK=101,CTL=<ACK>)     -->    CLOSED
2MSL(TIME_WAIT)
CLOSED

 

发送方接收到ACK时，在重发队列中所有的SEGMENT，如果SEG.SEQ + SEG.LEN <= ACK.SEQ，则这个SEGMENT被接收者确认（Acknowledged），并可以从队列中移出。

 

 今天同事做技术交流的时候带回来了一些问题：

１、三次握手完成之前是否需要accept操作，从上面的握手过程可以知道，只有三次握手完成之后，网络栈才会认为这个东西是正确的。然后才会交给应用进程去处理。

２、主进程和子进程之间共享socket文件描述符时候，比如nginx，三次握手的时候（中间过程），netstat的时候，这个连接是的进程号是谁的？其实这个现象是不确定的，比如centos平台上面，netstat的时候，进程号部分为-，即不知道这个连接归那个进程号所有。

３、linux平台上面只要拿到文件描述符就可以对socket进行accept，比如nginx的二进制文件升级的时候，用的就是这个特性。

 

其实这些东西都还是些linux 编程的东西，还是回去好好搞LINUX内核和LINUX平台上的编程？FUCK