linux第7天

TCP/IP的11种状态

建立连接时, TCP B先处于listen状态, A 发送一个请求SYN a, B接受到进行连接,然后发送一个b和a + 1,其中b代表B请求A的连接,a + 1代表回应A请求成功.最后A回应给B a+1,代表B的请求成功

看上去有点抽象,举个形象的例子,A代表男孩,B代表女孩   男孩叫女孩开房,女孩回复说好的,男孩就进入ESTABLISHED状态,女孩问男孩是不是喜欢自己,男孩说是,女孩子进入ESTABLISHED状态.

以上就是三次握手的过程.

断开连接时,A 主动关闭套接字,会给B发送一个FIN x字段(0个字节,B一般可以通read的返回值来判断A是否关闭套接字),B收到之后TCP会悄悄地回应A一个x + 1,代表B已经收到A的退出消息,A处于FIN_WAIT_2状态,B处于CLOSE_WAIT状态,

如果B此时也关闭套接字,那么A将会处于TIME_WAIT状态,一段时候会消除.B也消除.

形象的例子,男女朋友分手,男人说我想分手,并把女人送给男人的东西还给女人,女人收下后说我知道了.这时男人处于FIN_WAIT_2状态(半连接),女人处于CLOSE_WAIT状态(等待下决心彻底放下男人),

女人经过思想斗争后,对男人说,我同意分手,并把男人送给女人的东西还给男人,这时,男人处于TIME_WAIT状态,一直目送女人离开.

理解0：什么是主动套接字，什么是被动套接字？服务端口在listen前是主动套接字,之后变成被动套接字

理解1:为什么TCP/IP要三次握手，和四次断开？因为tcp/ip是可靠连接,频繁的握手与断开是为了信息稳定.

理解2：客户端状态向前推进过程，服务器端状态向前推进过程

理解3：执行主动关闭的那一端，进入TIME_WAIT状态

理解4：TIME_WAIT 时间是多长2MSL （2倍的最大生命期时间）

原因：（ACK y+1）如果发送失败可以重发。

服务器端处于closed状态，不等于客户端也处于closed状态。。

理解5：图上几种状态，还有一种CLOSING状态

两端同时关闭         将产生closing状态，最后双方都进入TIME_WAIT状态。

如果对方socket已关闭，已方再发写数据，则会产生SIGPIPE信号

SIGPIPE信号会让进程终止（man 7 signal，阅读SIGPIPE默认ACT）

往一个已经接收FIN的套接中写是允许的，接收到FIN仅仅代表对方不再发送数据。

在收到RST段之后，如果再调用write就会产生SIGPIPE信号，对于这个信号的处理我们通常忽略即可。

signal(SIGPIPE, SIG_IGN);

close终止了数据传送的两个方向.

shutdown可以有选择的终止某个方向的数据传送或者终止数据传送的两个方向。

shutdown how=1就可以保证对等方接收到一个EOF字符，而不管其他进程是否已经打开了套接字。而close不能保证，直到套接字引用计数减为0时才发送。也就是说直到所有的进程都关闭了套接字。

阻塞I/O

说明1：当上层应用app1调用recv系统调用时，如果对等方没有发送数据（缓冲区没有数据），上层应用app1将阻塞（默认行为，被linux内核阻塞）；

说明2：当对等方发送了数据，linux内核recv端缓冲区，有数据后，内核会把数据copy给用户空间。然后上层应用app1解除阻塞，执行下一步操作。

非阻塞I/O

说明1：上层应用程序app2将套接字设置成非阻塞模式。

说明2：上层应用程序app2轮询调用recv函数，接受数据。若缓冲区没有数据，上层程序app2不会阻塞，recv返回值为-1，错误码是EWOULDBLOCK。

说明3：上层应用程序不断轮询有没有数据到来。会造成上层应用忙等待。大量消耗CPU。很少直接用。应用范围小，一般和selectIO复用配合使用。

I/O复用

说明1：上层应用程序app3调用select机制（该机制有linux内核支持，避免了app3忙等待。），进行轮询文件描述符的状态变化。

说明2：当select管理的文件描述符没有数据（或者状态没有变化时），上层应用程序app3也会阻塞。

说明3：好处select机制可以管理多个文件描述符

说明4：select可以看成一个管理者，用select来管理多个IO。

一旦检测到的一个I/O或者多个IO，有我们感兴事件，发生，select函数将返回，返回值为检测到的事件个数。进而可以利用select相关api函数，操作具体事件。

说明5：select函数可以设置等待时间，避免了上层应用程序app3，长期僵死。

说明6: 和阻塞IO模型相比，selectI/O复用模型相当于提前阻塞了。等到有数据到来时，再调用recv就不会发生阻塞。

信号驱动I/O

说明1：上层应用程序app4建立SIGIO信号处理程序。当缓冲区有数据到来，内核会发送信号告诉上层应用程序app4。

说明2：上层应用程序app4接收到信号后，调用recv函数，因缓冲区有数据，recv函数一般不会阻塞。

说明3：这种用于模型用的比较少，属于典型的“拉模式”。即：上层应用app4,需要调用recv函数把数据拉进来。

异步I/O

说明1：上层应用程序app5调用aio_read函数，同时提交一个应用层的缓冲区buf；调用完毕后，不会阻塞。上层应用程序app5可以继续其他任务。

说明2：当tcpip协议缓冲区有数据时，linux主动的把内核数据copy到用户空间。然后再给上层应用app5发送信号；告诉app5数据有了，赶快处理吧！

说明3：典型的“推模式”

说明4：效率最高的一种形式，上层应用程序app5有异步处理的能力（在linux内核的支持下，言外之意：处理其他任务的同时，也可支持IO通讯）。异步I/O指的是什么？

上层应用程序app5，在也可以干别的活的时，可以接收数据（接受异步通信事件。===）异步命令来源）。与信号驱动IO模型，上层应用程序app5不需要调用recv函数。

int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,  struct timeval *timeout);

                   如果成功，返回所有sets中描述符的个数；如果超时，返回0；如果出错，返回-1。

• 监视readfds来查看是否read的时候会被堵塞，注意，即便到了end-of-file，fd也是可读的。
• 监视writefds看写的时候会不会被堵塞。
• 监视exceptfd是否出现了异常。主要用来读取OOB数据，异常并不是指出错。
• 注意当一个套接口出错时，它会变得既可读又可写。
• 如果有了状态改变，会将其他fd清零，只有那些发生改变了的fd保持置位，以用来指示set中的哪一个改变了状态。
• 参数n是所有set里所有fd里，具有最大值的那个fd的值加1

fd_set

四个宏用来对fd_set进行操作：

FD_CLR(int fd, fd_set *set);

FD_ISSET(int fd, fd_set *set);

FD_SET(int fd, fd_set *set);

FD_ZERO(fd_set *set);

• FD_ZERO用来清空set；
• FD_SET和FD_CLR用来对某个set添加和删除一个fd；
• FD_ISSET用来指示一个fd是不是一个set的一部分。他很有用，用来看select后哪一个fd可用了。

time_out

timeout是从调用开始到select返回前，会经历的最大等待时间。

两种特殊情况：如果为值为0，会立刻返回。

如果timeout是NULL,会阻塞式等待。

struct timeval {

long        tv_sec;            /* seconds */

long        tv_usec;         /* microseconds */

};

一些调用使用3个空的set, n为zero, 一个非空的timeout来达到较为精确的sleep.

Linux中, select函数改变了timeout值，用来指示还剩下的时间，但很多实现并不改timeout。

为了较好的可移植性，timeout在循环中需要被重新赋初值。

• timeout== NULL

–  无限等待

–  被信号打断时返回1, errno 设置成EINTR

• timeout->tv_sec == 0 && tvptr->tv_usec == 0

–  不等待立即返回

• timeout->tv_sec != 0 || tvptr->tv_usec != 0

–  等待特定时间长度, 超时返回0