（1）客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。
（2） 服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。
（3） 客户必须再次回应服务段一个ACK报文，这是报文段3。2、连接终止协议（四次挥手）
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段4）。
（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。
（3） 服务器关闭客户端的连接，发送一个FIN给客户端（报文段6）。
（4） 客户段发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。CLOSED:这个没什么好说的了，表示初始状态。LISTEN:这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。SYN_RCVD:这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。SYN_SENT:这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。ESTABLISHED：
这个容易理解了，表示连接已经建立了。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:这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。
一、会话和作业的概念：
1、进程：Linux自身运行的独立程序。
2、进程组：进程组是一个或多个进程的集合。
_____________________________________________________
Linux包括三种不同类型的进程，每种进程都有自己的特点和属性：
3、交互进程 —— 由一个shell启动的进程。交互进程既可以在前台运行，也可以在后台运行。
4、批处理进程 —— 这种进程和终端没有联系，是一个进程序列。
5、监控进程（也称守护进程）—— linux系统启动时启动的进程，并在后台运行。
_______________________________________________________________
6、会话：一个用户登录终端后会新建一个会话，它是和控制终端产生IO交互的过程。这个过程可以称之为会话期。会话期可以产生一个 或 多个进程组的集合。（比喻打电话，首先要电话的接通，接通了才可以产生人与人之间的信息交互。在此会话期间可以产生一个或多个不同范畴的话题）
7、作业：作业类似于用户提交给系统的一个任务。一个作业可以包含一个或多个进程共同完成一个任务。（比喻会议上BOSS需要完成一个任务，根据需求可以分配到一个或多个人配合完成。）
8、作业控制：指的是控制正在运行的进程的行为。比如，用户可以挂起一个进程，等一会儿再继续执行该进程。这样用户就能在多个独立作业间进行切换。（比喻正在进行常规工作的员工，经理突发一个事情需要协助处理。这位员工放下手上的工作（挂起）。首先处理经理安排的事情，完事后再处理常规工作的事情。）
二、通过 date 和 sleep 命令理解前台、后台作业。date 命令是显示系统时间，sleep 命令是设置延时。
1、前台执行命令：
1）、前台执行命令。输入输出都是按部就班，执行完一个命令再执行下一个命令，把结果打印出来。
红色下划线：date 查看当前日期时间。
黄色下划线：sleep 10 延时10秒。
蓝色下划线：date 查看当前日期时间。
通过结果可以看出第一个 date 打印出日期时间后，延时10再执行一个 date 打印日期时间。两个时间相隔 10 秒。
2）、系统正在执行前台的命令时，再输入命令是不会马上执行。要执行完毕前面的命令才可以执行后面输入的命令。同样用 date 和 sleep做实验：
红色下划线：date 输出当前日期时间。
黄色下划线：sleep 60 系统执行延时 60 秒的 *** 作。 [root@localhost ~]# 用户标识符没有出现。虽然光标可以进行输入，但输入的 ls /tmp/ 命令并没有马上执行，没有输出。因为此时，前台正在执行 sleep 60 延时60秒的指令。
红色下划线：等待 sleep 60 执行完毕后，再执行一个 date 输出当前日期时间。两个 date 之间时间相隔 60 秒。
黄色下划线：待整条 date sleep 60 date 命令都执行完毕后，再执行刚才延时 60 秒时输入的 ls /tmp/ 命令，输出结果。
蓝色下划线：[root@localhost ~]# 用户标识符出现才算前台命令执行完毕，可以继续正常 *** 作。
2、后台执行命令：
&：命令后面使用 &符号，可以让命令在后台执行。
jobs：可以查看正在后台运行的作业。
jobs选项：-l —— 除了列出作业号外，同时列出 PID。
-r —— 列出仅仅在后台运行的作业。
-s —— 列出仅仅再后台暂停的作业。
1）、后台运行的命令进程不会影响到前台命令进程。
红色下划线：sleep 30 &—— 把 sleep 30 丢到后台运行。
黄色下划线：通过 jobs 命令跟踪进程情况。（Runing —— 正在运行，Done —— 完成）
绿色下划线：sleep 后台运行期间进行了 ls 和 tail 命令的查询输出，正常运作。
蓝色下划线：jobs 没有输出，代表 sleep 已经完结，没有后台进程。
2）、挂起 和 中断后台运行的命令。
Ctrl+c：中断后台进程。Ctrl+z：挂起后台进程。
jobs 命令可以查看到挂起的命令，不可以查看中断的命令。
3）、jobs选项：-l —— 除了列出作业号外，同时列出 PID。
红色下划线：sleep 100 &，后台运行延时100秒的程序。
黄色下划线：jobs -l 列出所有后台进程（-l —— 含作业号、PID、运行状态 和 执行的命令。）
运行状态有 Running 、Stopped 和 Done，后台正在运行会显示 Running，当运行完毕后用 jobs 查看会显示 Done，并且命令后面的 &符号也会消失。Done只出现一次，下次再用 jobs 查看后台程序就没有了系统曾提示过 Done 的命令。挂起正在运行的命令，后台会显示 Stopped 暂停状态。
-r —— 列出仅仅在后台运行的作业。
-s —— 列出仅仅再后台暂停的作业。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）