- 软中断：
- 软中断的处理非常像硬中断。然而，它们仅仅是由当前正在运行的进程所产生的。
- 通常，软中断是一些对I/O的请求。这些请求会调用内核中可以调度I/O发生的程序。对于某些设备，I/O请求需要被立即处理，而磁盘I/O请求通常可以排队并且可以稍后处理。根据I/O模型的不同，进程或许会被挂起直到I/O完成，此时内核调度器就会选择另一个进程去运行。I/O可以在进程之间产生并且调度过程通常和磁盘I/O的方式是相同。
- 软中断仅与内核相联系。而内核主要负责对需要运行的任何其他的进程进行调度。一些内核允许设备驱动的一些部分存在于用户空间，并且当需要的时候内核也会调度这个进程去运行。
- 软中断并不会直接中断CPU。也只有当前正在运行的代码（或进程）才会产生软中断。这种中断是一种需要内核为正在运行的进程去做一些事情（通常为I/O）的请求。有一个特殊的软中断是Yield调用，它的作用是请求内核调度器去查看是否有一些其他的进程可以运行。
-
tcp连接的状态图：
image.png
tcp的所有状态：
CLOSED: 这个没什么好说的了，表示初始状态。
LISTEN: 这个也是很easy理解的一个状态。表示server端的某个SOCKET处 于监听状态，能够接受连接了。
SYN_RCVD: 这个状态表示接受到了SYN报文。在正常情况下，这个状态是server端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态。非常短暂，基本上用netstat你是非常难看到这样的状态的，除非你特意写了一个client測试程序。有益将三次TCP握手过程中最后一个ACK报文不予发送。因此这样的状态时，当收到client的ACK报文 后，它会进入到ESTABLISHED状态。
SYN_SENT: 这个状态与SYN_RCVD遥想呼应。当clientSOCKET运行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。
SYN_SENT状态表示client已发送SYN报文。
ESTABLISHED：这个easy理解了，表示连接已经建立了。
FIN_WAIT_1: 这个状态要好好解释一下，事实上FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的差别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。
而当对方回应ACK报文后，则进入到FIN_WAIT_2状态。当然在实际的正常情况下，不管对方何种情况下，都应该立即回应ACK报文，所以FIN_WAIT_1状态通常是比較难见到的。而FIN_WAIT_2状态还有时经常能够用netstat看到。
FIN_WAIT_2：上面已经详解了这样的状态，实际上FIN_WAIT_2状态下的SOCKET。表示半连接，也即有一方要求close连接，但另外还告诉对方，我临时还有点数据须要传送给你，稍后再关闭连接。
TIME_WAIT: 表示收到了对方的FIN报文。并发送出了ACK报文，就等2MSL后就可以回到CLOSED可用状态了。假设FIN_WAIT_1状态下。收到了对方同一时候带FIN标志和ACK标志的报文时，能够直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
CLOSING: 这样的状态比較特殊。实际情况中应该是非常少见，属于一种比較罕见的例外状态。
正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同一时候收到）对方的ACK报文，再收到对方的FIN报文。
可是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。
什么情况下会出现此种情况呢？事实上细想一下。也不难得出结论：那就是假设两方差点儿在同一时候close一个SOCKET的话。那么就出现了两方同一时候发送FIN报文的情况，也即会出现CLOSING状态，表示两方都正在关闭SOCKET连接。
CLOSE_WAIT: 这样的状态的含义事实上是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方。此时则进入到CLOSE_WAIT状态。接下来呢。实际上你真正须要考虑的事情是察看你是否还有数据发送给对方，假设没有的话，那么你也就能够close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下。须要完毕的事情是等待你去关闭连接。
LAST_ACK: 这个状态还是比較easy好理解的。它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即能够进入到CLOSED可用状态了。
