TCP协议是TCP/IP协议族中的一个十分重要的名字（看到TCP/IP这个名字就知道TCP有多重要了），同时也是一个十分复杂的协议，在使用这个协议的时候可能会带来很多问题，这使得使用的程序员会十分头大。如果想了解TCP协议的细节，可以参考《TCP/IP详解1：协议》。闲话不多说，我们进入正题：
一、报文头
首先我们来看一下TCP协议的报文头：
TCP是传输层协议，其报文头并不包含TP地址，IP地址会在IP层添加，当然，IP层处于TCP的下层，IP层的报文内容就是TCP报文。
TCP/IP协议网络传输使用大端表示。网络之间传输的数据全部使用大端表示，这意味着，Source Port和Destination Port都是大端表示的两个字节的无符号数字（unsigned short/uint16_t）；
Sequence Nember是包的序号，用来解决网络乱序问题；
Acknowledgement Number就是ACK，是对已收到数据的确认，用来解决网络丢包的问题；
Window就是注明的滑动窗口，用来进行流量控制和拥塞控制；
TCP Flag是包的类型，主要用于操控TCP的状态。
Checksum是校验和，是用来对已收到的报文进行校验的。
二、TCP状态转换
实际上网络传输是不可靠的，然而TCP却要在不可靠的网络环境中实现可靠的传输，其实现的原理是确认-重发机制，通过对已收到的片段数据进行确认，没有确认的数据会重发，于是就需要有一种机制用来识别接下来还有没有数据，这种机制就是“链接”。链接的意思并不是真正意义上的链接，而是Client端和Server端的协议链接，是双方维护的一种“链接状态”，TCP Client和Server之间从关闭到链接中间有一个“TCP建立链接”、“传输数据”和“TCP断开链接”的过程，下面是TCP协议的状态转换图：
1、3次握手链接
3次握手链接主要是为了是TCP链接从CLOSED（LISTEN）状态转换成ESTABLISHED状态，其具体变化过程如下：
第一次握手：Client向Server发送一个{SYN|seq=x}信号，请求建立链接，Client由CLOSED状态变成SYN_SENT状态；
第二次握手：Server收到Client发来的建立链接请求之后，回复Client一条确认{SYN|seq=y,ack=x+1}，Server由LISTEN状态变成SYN_RCVD状态，其中seq是Server自己的数据编号，ack是对Client发来的数据的确认；
第三次握手：Client收到Server发来的同意建立请求之后，向Server发送一条确认{ACK=y+1}，由SYN_SENT状态变成ESTABLISHED状态，如此，Client变建立好了链接，Server收到Client发来的确认之后便进入ESTABLISHED状态，Server完成链接的建立。
2、4次握手断开
4次握手断开的目的是断开TCP链接，由ESTABLISHED状态变成CLOSED状态；
第一次握手：Client主动发起断开链接，向Server发送断开连接请求{FIN|seq=x+2,ACK=y+1}，然后Client由ESTABLISHED状态变成FIN_WAIT_1状态；
第二次握手：Server收到断开连接请求之后，对断开链接请求恢复一个确认{ACK=x+3}，然后Server进入CLOSE_WAIT状态，Client收到确认之后进入FIN_WAIT_2状态，此时Client端的写链接断开；
第三次握手：Server向Client发送断开联接请求{FIN|seq=y+1}，Server由CLOSE_WAIT状态变成LAST_ACK状态，Client收到请求之后，回复一个确认{ACK=y+2}，状态由TIME_WAIT状态；
第四次握手：Server收到确认之后进入CLOSED状态，由此Server端写链接断开，Client端经过一段时间之后自动进入CLOSED状态。
3、几点说明
a.建立链接时，Server端一定先进入LISTEN状态，才能接受建立链接；
b.建立链接时，一定是由Client端发起的；
c.断开链接时，不一定是Client端发起的，Server也可以发起断开链接，这里的Client代指发起断开链接的一方；
d.TIME_WAIT状态其实就是等待一段时间，确保Server已经收到自己回复的确认，如果Server没有收到确认会在这段时间里重复发送上一条数据{FIN|seq=y+1}；
e.如果两边同时发起断开链接，则会进入特殊的状态CLOSING：
第一次握手：Clientf发起断开链接，向Server发送一条请求{FIN|seq=x+2,ACK=y+1}，由ESTABLISHED状态变成FIN_WAIT_1状态；
第二次握手：Server发起断开链接，向Client发送一条请求{FIN|seq=y+1,ACK=x+2}，由ESTABLISHED状态变成FIN_WAIT_1状态；
第三次握手：Server收到Client发来的断开链接请求（而不是对自己的确认），于是回复一条确认{ACK=x+3}，由FIN_WAIT_1状态变成CLOSING状态；
第四次握手：Client收到Server发来的断开链接请求（而不是对自己的确认），于是回复一条确认{ACK=y+2}，由FIN_WAIT_1状态变成CLOSING状态；
Client和Server各自收到对自己的确认之后进入TIME_WAIT状态，一段时间之后自动进入CLOSED状态。
f.如果server端接到了clien发的SYN后回了SYN-ACK后client掉线了，server端没有收到client回来的ACK，那么，这个连接处于一个中间状态，即没成功，也没失败。于 是，server端如果在一定时间内没有收到的TCP会重发SYN-ACK。在Linux下，默认重试次数为5次，重试的间隔时间从1s开始每次都翻售，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s都知道第5次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 2^6 -1 = 63s，TCP才会把断开这个连接。
g.关于SYN Flood攻击：一些恶意的人就为此制造了SYN Flood攻击--给服务器发了一个SYN后，就下线了，于是服务器需要默认等63s才会断开连接，这样，攻击者就可以 把服务器的syn连接的队列耗尽，让正常的连接请求不能处理。于是，Linux下给了一个叫tcp_syncookies的参数来应对这个事——当SYN队列满了后，TCP会通过源地址 端口、目标地址端口和时间戳打造出一个特别的Sequence Number发回去（又叫cookie），如果是攻击者则不会有响应，如果是正常连接，则会把这个 SYN Cookie发回 来，然后服务端可以通过cookie建连接（即使你不在SYN队列中）。请注意，请先千万别用tcp_syncookies来处理正常的大负载的连接的情况。因为，synccookies是妥协 版的TCP协议，并不严谨。对于正常的请求，你应该调整三个TCP参数可供你选择，第一个是：tcp_synack_retries 可以用他来减少重试次数；第二个是： tcp_max_syn_backlog，可以增大SYN连接数；第三个是：tcp_abort_on_overflow 处理不过来干脆就直接拒绝连接了。
h.关于TIME_WAIT数量太多：TIME_WAIT是个很重要的状态，但是如果在大并发的短链接下，TIME_WAIT 就会太多，这也会消耗很多系统资源。只要搜一下，你就会发 现，十有八九的处理方式都是教你设置两个参数，一个叫tcp_tw_reuse，另一个叫tcp_tw_recycle的参数，这两个参数默认值都是被关闭的，后者recyle比前者resue更为 激进，resue要温柔一些。另外，如果使用tcp_tw_reuse，必需设置tcp_timestamps=1，否则无效。这里，你一定要注意，打开这两个参数会有比较大的坑--可能会让TCP 连接出一些诡异的问题。
三、Linux网络编程
socket：
int socket(int domain, int type,intprotocol)
domain：说明我们网络程序所在的主机采用的通讯协族(AF_UNIX和AF_INET等)。
AF_UNIX只能够用于单一的Unix 系统进程间通信，而AF_INET是针对Internet的,因而可以允许在远程主机之间通信(当我们 mansocket时发现domain可选项是 PF_*而不是 AF_*,因为glibc是posix的实现所以用PF代替了AF，不过我们都可以使用的)。
type:我们网络程序所采用的通讯协议(SOCK_STREAM,SOCK_DGRAM等)
SOCK_STREAM表明我们用的是TCP 协议，这样会提供按顺序的,可靠,双向,面向连接的比特流。
SOCK_DGRAM 表明我们用的是UDP协议，这样只会提供定长的,不可靠,无连接的通信。
protocol：由于我们指定了type，所以这个地方我们一般只要用0来代替就可以了socket为网络通讯做基本的准备。
成功时返回文件描述符,失败时返回-1，看errno可知道出错的详细情况。
bind：
int bind(int sockfd, struct sockaddr*my_addr, int addrlen)
sockfd：是由socket调用返回的文件描述符。
addrlen：是sockaddr结构的长度。
my_addr：是一个指向sockaddr的指针。
其中sockaddr的定义如下：
struct sockaddr{
unisgned short as_family;
char sa_data[14];
};
不过由于系统的兼容性，我们一般不用这个头文件,而使用另外一个结构(struct sockaddr_in) 来代替。在中有sockaddr_in的定义
struct sockaddr_in{
unsigned short sin_family;
unsigned short int sin_port;
struct in_addr sin_addr;
unsigned char sin_zero[8];
}
我们主要使用Internet所以
sin_family一般为AF_INET，
sin_addr设置为INADDR_ANY表示可以和任何的主机通信，
sin_port是我们要监听的端口号。sin_zero[8]是用来填充的。
bind将本地的端口同socket返回的文件描述符捆绑在一起.成功是返回0，失败的情况和socket一样。
listen：
int listen(int sockfd,int backlog)
sockfd：是bind后的文件描述符。
backlog：设置请求排队的最大长度。当有多个客户端程序和服务端相连时， 使用这个表示可以介绍的排队长度。
listen函数将bind的文件描述符变为监听套接字。回的情况和bind一样。
accept：
int accept(int sockfd, structsockaddr *addr,int *addrlen)
sockfd：是listen后的文件描述符。
addr，addrlen是用来给客户端的程序填写的,服务器端只要传递指针就可以了。bind,listen和accept是服务器端用的函数，accept调用时，服务器端的程序会一直阻塞到有一个客户程序发出了连接。accept成功时返回最后的服务器端的文件描述符，这个时候服务器端可以向该描述符写信息了，失败时返回-1。
connect：
int connect(int sockfd, structsockaddr * serv_addr,int addrlen)
sockfd：socket返回的文件描述符。
serv_addr：储存了服务器端的连接信息.其中sin_add是服务端的地址
addrlen：serv_addr的长度
connect函数是客户端用来同服务端连接的，成功时返回0，sockfd是同服务端通讯的文件描述符失败时返回-1。
write：
ssize_t write(int fd, const void*buf, size_t count);
fd：文件描述符，就是socket的返回的值（非负），
buf：指向要发送的数据，count为要发送的字符数。
返回发送的数据的字节数。如果失败，则返回-1。
read：
ssize_t read(int fd,void *buf,size_t nbyte)fd：文件描述符，就是socket的返回的值（非负），
buf：指向用于写数据的缓存，nbyte为缓存的大小。
返回读取的数据的字节数。如果失败，则返回-1。
close：
int close(int fd);
用于关闭连接，fd为文件描述符，就是socket返回的非负值。
关闭成功，则返回0，失败返回-1。
几点说明：
1、Client端connect一定要在Server端listen之后调用才有可能成功，否则立即返回错误；
2、Server端listen之后，Client端的connect会阻塞，直到Server端accept之后才会返回；
3、Server端的accept会一直阻塞，直到Client端connect之后才返回；
4、在Server端listen之后，Client端发起connect，但是在Server端accept之前有放弃了链接（可能是发来了复位信号，也可能等待超时），然后Server端再accept，此时accept会返回一个错误（-1），遇到这种错误，只需要再次调用accept即可。
5、read数据时，如果此时没有数据，会一直阻塞，直到收到数据之后才返回。
6、write数据时，只是先将数据写到内核的发送缓存中，并没有真正的发送出去。
7、如果内核缓存满了，此时write会阻塞，直到内核缓存里的数据被发送出去，才会把数据写到缓存，在返回。
8、connect和accept都是在3次握手完成之后才返回（如果3次握手没有成功，则返回失败）。
9、close并不是在4次握手完成之后返回，发送了断开链接请求就返回，可以设置TCP选项来是close在4次握手完成之后再返回。
版权声明：本文为博主原创文章，未经博主允许不得转载。
原文地址：http://blog.csdn.net/ghaitian/article/details/48104633
