[code.nginx] Nginx服务器高级配置

这里提及的参数是和IPv4网络有关的Linux内核参数。我们可以将这些内核参数的值追加到Linux系统的/etc/sysctlconf文件中，然后使用如下命令使修改生效：

这些常用的参数包括以下这些。
1 netcorenetdev_max_backlog参数
netcorenetdev_max_backlog，表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许发送到队列的数据包的最大数目。一般默认值为128（可能不同的Linux系统该数值也不同）。Nginx服务器中定义的NGX_LISTEN_BACKLOG默认为511我们可以将它调整一下：

2netcoresomaxconn参数
该参数用于调节系统同时发起的TCP连接数，一般默认值为128。在客户端存在高并发请求的情况下，在默认值较小，可能导致链接超时或者重传问题，我们可以根据实际需要结合并发请求数来调节此值。

3netipv4tcp_max_orphans参数
该参数用于设定系统中最多允许存在多少TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，没有与用户文件句柄关联的TCP套接字将立即被复位，同时给出警告信息。这个限制只是为了防止简单的DoS(Denial of Service，拒绝服务)攻击。一般在系统内存比较充足的情况下，可以增大这个参数的赋值：

4netipv4tcp_max_syn_backlog参数
该参数用于记录尚未收到客户端确认信息的连接请求的最大值。对于拥有128MB内存的系统而言，此参数的默认值是1024，对小内存的系统则是128。一般在系统内存比较充足的情况下，可以增加这个参数的赋值：

5netipv4tcp_timestamps参数
该参数用于设置时间戳，这可以避免序列号的卷绕。在一个1Gb/s的链路上，遇到以前用过的序列号的概率很大。当此值赋值为0时，禁用对于TCP时间戳的支持。在默认情况下，TCP协议会让内核接受这种“异常”的数据包。针对Nginx服务器来说，建议将其关闭：

6netipv4tcp_synack_retries参数
该参数用于设置内核放弃TCP连接之前向客户端发送SYN+ACK包的数量。为了建立对端的连接服务，服务器和客户端需要进行三次握手，第二次握手期间，内核需要发送SYN并附带一个回应前一个SYN的ACK，这个参数主要影响这个进程，一般赋值为1，即内核放弃连接之前发送一次SYN+ACK包，可以设置其为：

7netipv4tcp_syn_retries参数
该参数的作用和上一个参数类似，设置内核放弃建立连接之前发送SYN包的数量，它的赋值和上个参数一样即可：

在Nginx配置文件中，有这样两个指令：worker_processes和worker_cpu_affinity，它们可以针对多核CPU进行配置优化。
1worker_processes指令
worker_processes指令用来设置Nginx服务的进程数。官方文档建议此指令一般设置为1即可，赋值太多会影响系统的IO效率，降低Nginx服务器的性能。为了让多核CPU能够很好的并行处理任务，我们可以将worker_processes指令的赋值适当的增大一些，最好是赋值为机器CPU的倍数。当然，这个值并不是越大越好，Nginx进程太多可能增加主进程调度负担，也可能影响系统的IO效率。针对双核CPU，建议设置为2或
4。如果是四核CPU，设置为：

设置好worker_processes指令之后，就很有必要设置worker_cpu_affinity指令。

2 worker_cpu_affinity指令
worker_cpu_affinity指令用来为每个进程分配CPU的工作内核。这个指令用来为每个进程分配CPU的工作内核。这个指令的设置方法有些麻烦。
如下图所示：

worker_cpu_affinity指令的值是由几组二进制值表示的。其中，每一组代表一个进程，每组中的每一位表示该进程使用CPU的情况，1表示使用，0表示不使用。注意，二进制位排列顺序和CPU的顺序是相反的。建议将不同的进程平均分配到不同的CPU运行内核上。
如果设置的Nginx服务的进程数为4，CPU为4核，因此会有四组值，并且每组有四位，所以，此指令的设置为：

四组二进制数值分别对应4个进程，第一个进程对应0001，表示使用第一个CPU内核。第二个进程对应0010，表示使用第二个CPU内核，以此类推。
如果将worker_processes指令的值赋值为8，即赋值为CPU内核个数的两倍，则worker_cpu_affinity指令的设置可以是：

如果一台机器的CPU是八核CPU，并且worker_processes指令的值赋值为8，那么worker_cpu_affinity指令的设置可以是：

1keepalive_timeout指令
该指令用于设置Nginx服务器与客户端保持连接的超时时间。
这个指令支持两个选项，中间用空格隔开。第一个选项指定客户端连接保持活动的超时时间，在这个时间之后，服务器会关闭此连接。第二个选项可选，其指定了使用Keep-Alive消息头保持活动的有效时间，如果不设置它，Nginx服务器不会向客户端发送Keep-Alive消息头以保持与客户端某些浏览器（如Mozilla、Konqueror等）的连接，超过设置的时间后，客户端就可以关闭连接，而不需要服务器关闭了。你可以根据自己的实际情况设置此值，建议从服务器的访问数量、处理速度以及网络状态方面考虑。下面是此指令的设置示例：

该设置表示Nginx服务器与客户端连接保持活动的时间是60s，60s后服务器与客户端断开连接。使用Keep-Alive消息头保持与客户端某些浏览器（如Mozilla、Konqueror等）的连接时间为50s，50s后浏览器主动与服务器断开连接。

2send_timeout指令
该指令用于设置Nginx服务器响应客户端的超时时间，这个超时时间仅针对两个客户端和服务器之间建立连接后，某次活动之间的时间。如果这个时间后客户端没有任何活动，Nginx服务器将会关闭连接。此指令的设置需要考虑服务器访问数量和网络状况等方面。下面是此指令的设置示例：

该设置表示Nginx服务器与客户端建立连接后，某次会话中服务器等待客户端响应超时10s，就会自动关闭连接。

3client_header_buffer_size指令
该指令用于设置Nginx服务器允许的客户端请求头部的缓冲区大小，默认为1KB。此指令的赋值可以根据系统分页大小来设置。分页大小可以用以下命令取得：

有过Nginx服务器工作经验的可能遇到Nginx服务器返回400错误的情况。查找Nginx服务器的400错误原因比较困难，因为此错误并不是每次都会出现，出现错误的时候，通常在浏览器和日志里也看不到任何有关提示信息。根据实际的经验来看，有很大一部分情况是客户端的请求头部过大造成的。请求头部过大，通常是客户单cookie中写入了较大的值引起的。于是适当增大此指令的赋值，允许Nginx服务器接收较大的请求头部，可以改善服务器对客户端的支持能力。一般将此指令赋值为4KB大小，即：

4multi_accept指令
该指令用于配置Nginx服务器是否尽可能多的接收客户端的网络连接请求，默认值为off。

本节涉及的指令与Nginx服务器的事件驱动模型密切相关。

其中，number为设置的最大数量。结合worker_processes指令，我们可以计算出Nginx服务器允许同时连接的客户端最大数量Client = worker_processes worker_connections / 2;
在使用Nginx服务器的过程中，笔者曾经遇到过无法访问Nginx服务器的情况，查看日志发现一直在报如下错误:

根据报错信息，推测可能是Nginx服务器的最大访问连接数设置小了。此指令设置的就是Nginx服务器能接受的最大访问量，其中包括前端用户连接也包括其他连接，这个值在理论上等于此指令的值与它允许开启的工作进程最大数的乘积。此指令一般设置为65535：

此指令的赋值与linux *** 作系统中进程可以打开的文件句柄数量有关系。按照以上设置修改此项赋值以后，Nginx服务器报以下错误：

究其原因，Linux系统中有一个系统指令open file resource limit，它设置了进程可以打开的文件句柄数量。worker_connections指令的赋值当然不能超过open file resource limit的赋值。可以使用以下命令查看在你的Linux系统中open file resource limit的赋值。

可以通过一下命令将open file resource limit指令的值设为2390251：

这样，Nginx的worker_connections指令赋值为65535就没问题了。

其中，limit为Linux平台事件信号队列的长度上限值。
该指令主要影响事件驱动模型中rfsig模型可以保存的最大信号数。Nginx服务器的每一个工作进程有自己的事件信号队列用于暂存客户端请求发生信号，如果超过长度上线，Nginx服务器自动转用poll模型处理未处理器的客户端请求。为了保证Nginx服务器对客户端请求的高效处理，请大家根据实际的客户端并发请求数量和服务器运行环境的处理能力设定该值。设置示例为：

其中，number为要设置的数量，默认值均为32。

其中，number为要设置的数量，默认值均为512
使用kequeue_changes方式，可以设置与内核之间传递事件的数量。

其中，number为要设置的数量，默认值均为512。

7rtsig_signo指令
该指令用于设置rtsig模式使用的两个信号中的第一个，第二个信号是在第一个信号的编号上加1，语法为：

默认的第一个信号设置为SIGRTMIN+10。

提示
在Linux中可以使用一下命令查看系统支持的SIGRTMIN有哪些。

8rtsig_overflow_ 指令
该指令代表三个具体的指令，分别为rtsig_overflow_events指令、rtsig_overflow_test指令和rtsig_overflow_threshold指令。这些指令用来控制当rtsig模式中信号队列溢出时Nginx服务器的处理方式，语法结构为：

其中，number是要设定的值。
rtsig_overflow_events指令指定队列溢出时使用poll库处理的事件数，默认值为16。
rtsig_overflow_test指令设定poll库处理完第几件事件后将清空rtsig模型使用的信号队列，默认值为32。

rtsig_overflow_threshold指令指定rtsig模式使用的信号队列中的事件超过多少时就需要清空队列了。

为应用程序池 ‘DefaultAppPool’ 提供服务的进程关闭时间超过了限制
服务器经常产生“应用程序池 ‘DefaultAppPool’ 提供服务的进程关闭时间超过了限制。进程 ID 是 ‘2068′。”的错误，导致iis处于假死状态，经了解是IIS应用程序池的设置问题。解决方法如下：
Internet 信息服务(IIS)管理器－＞应用程序池－＞DefaultAppPool－＞右击属性
一、回收
1、回收工作进程（分钟）：选中，值为1740
2、回收工作进程（请求数目）：不选（原先设置为35000）
3、在下列时间回收工作进程：不填
4、消耗太多内存时回收工作进程：全不选。（2、3、4项可能避免了在访问量高的时候强制回收进程可能引发的服务器响应问题，导致iis假死不响应）
二、性能
只选中空闲超时20分钟。其他都不选。WEB园最大工作进程数为1（默认）。注意web园这里一定要保持默认，如果填写其他超过1的数字就会导致一些网站程序的后台程序打不开或者刷新不停。
原来的请求队列限制为4000，现在无限制。
三、运行状况
前两项都起用，是原来的默认设置。启动时间限制90秒，关闭时间限制180秒。
启动快速失败保护的钩去掉！
为了避免真的遇到很多错误时没有提示，可以不关闭，只是把快速保护的保护范围加大些，例如失败数50次 时间段5分钟 则关闭对应的程序。
“关闭时间限制180秒”是必须的，因为进程关闭的时间，原来为90秒限制,是默认值，如果进程关闭时间超过90秒，则认为超时，从而出现：进程关闭时间超过了限制 日志，所以，适当延长这个时间，可以避免这种错误
第2种方法：
原因：独立进程的 内存堆戋消耗完了，IIS不能创建更多的进程工作空间来处理
解决方法：
1 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC
2 在Parameters键下新建一个DWORD项，名字为：UseSharedWPDesktop 值为1 重启IIS
第3种
问题已解决,发现是数据库连接无法释放,不知道是什么原因,同样的代码在本地就是好的,在服务器端就有问题,最后在连接串里加入以下语句解决问题
Pooling=true; MAX Pool Size=512;Min Pool Size=50;Connection Lifetime=30
第4种
新建应用程序池，不同的网站引用不同程序池。
为应用程序池 ‘AppPool #1′ 提供服务的进程关闭时间超过了限制。进程 ID 是 ‘3000′。
出现上面情况后，该应用程序池对应的网站就访问的非常慢，几乎是打不开。
这种现象是不是iis假死？
重启下该站点，问题可以得到解决。
可能是应用程序池设置问题，不知道具体应该怎么设置！
请高手指点。
程序代码解决办法：
1 设置进程池回收时间在进程池属性里
2 如果你的程序是使用 asp + acc 数据库且acc数据库大于30m建议更换sql数据库 acc数据库大于这个值2003系统下会造成iis6的频繁假死2000下会造成dllhostexe占用大量cpu及内存资源都会严重影响 web访问速度
3 asp程序存在死循环
4 可使用 microsoft office 压缩修复acc数据库,须先备份
引用内容2003应用程序池假死常见问题及解决方法
2006-10-09 09:48
经常见到大家谈起，2003应用程序池自动死了，不能恢复了，一直出现 Service Unavailable 常见方法如下。
1：以前没有SP1打补丁的时候会出现这个IIS6。0假死问题，但现在微软都在自动更新里面出补丁了，一般你打好最新补丁后是不会出现此问题了。（所以现在的IIS假死与这个关系不是很大）
2：从IIS60开始CPU资源都在应用池里面限制了，不象以前的IIS。5。所以假死的池的缘故就是池被拉死，你在网站打不开的时候可以看到你的某个应用池是禁用的，上面出现一个红叉。你鼠标右键启动网站又会自动恢复。 这个原因：大概是以下几个因数造成的。
（1）：你限制了应用池的资源限制，限制得太小 比如：50这样或更少更多一点，这个时候如果你这个池下面的网站占用CPU太高，比如超过50% 那么5分钟后他就自动死了，手工默认建立的应用池默认是超过资源不 *** 作。
出现上面这个情况解决方法：1：不限制CPU资源，（这个是不可取的，不限制资源，有的程序有BUG占用资源厉害了的，服务器都会被拉死，你可能都无法 *** 作服务器。）2：在超过资源那里选择关闭，这个关闭默认是失败5次，90秒内恢复，一般默认就可。网站能自动恢复，这个关闭：不是永久关闭，意思是超过资源关闭，然后在某时间内自动恢复池。不 *** 作就是不恢复，这个是很多人的误区。上次我写过相关的这个讲解了。
（2）：内存限制 在IIS6。0应用池上面有虚拟内存和最大内存限制，如果你设置了这个。那么网站访问量大了 也会出现假死，所以不建议设置这里。默认就可。
3：就是服务器自身内存太小，网站运行当然需要使用到内存了，当内存不够的时候应用池也会死掉变成禁用。那么只有等内存全部释放出来才能恢复应用池了。出现这个情况：那么你就要考虑加内存或者检查到底是什么程序占用了内存了。比如MSSQL数据库，这个可是吃内存得大户啊，最好别和WEB服务器同时一个服务器上。很多人用1G内存做 2003系统，2003NET结构是很占用内存的，所以做服务器选2003还得把内存加到2G或更高才好。内存不够上面 2点讲到的，是没办法 *** 作了，也无法自动恢复。
4：就是ACCESS数据库太大或查询太多，这个也会出现把IIS拉死，解决方法；修复ACCESS数据库，或尽量少用ACCESS数据库。
5：不同网站用不同应用池：根据你自己实际情况而定，站点大的最好独立一个应用池，限制他的资源超过了自动回收，看上面（1）讲到的，这样就不影响其他站点。中型站点：多个网站共用一个应用池，比如5个站点用一个池，设置他资源时间等等。这样他们就算超资源了也不影响其他应用池的网站。
6：设置回收时间：很多人以为设置回收池越短越好，其实是错误的，每次回收当然是把内存回收回来了，但加重了一次服务器的负担，当服务器比较繁忙的时候，有可能导致其他应用池死。所以建议设置共1000就行了。其他独立池按照他网站流量而设置 可以设置600 也行，共用的不建议设置太短。
7：网站后台过不了多久自动退出又要重新登陆：这个情况就是你设置回收时间太短了，按照 6点设置吧。 不要设置什么20分、30分这样的，这样不好的。

前端socket有多个怎么关闭某一个，Copyright © 1999-2020, CSDNNET, All Rights Reserved


打开APP


socket的连接关闭的方式和过程 转载
2020-07-03 10:27:38
 2点赞

NeverGx 
码龄5年
关注
socket的关闭有close 和shutdown两种API，那么他们的区别在哪里呢？
close ----- 在多进程的情况下，关闭本进程的socket，但这只是socket的引用计数减1，用这个socket的其它进程还能用这个链接，能读或写这个socket，直到所有的进程都进行了close，才真正关闭这个套接字，但当它真正执行关闭的时候是完全关闭，既不处理发送也不处理接收数据。
shutdown – 即便在多进程的情况下面，也是直接进行关闭的，关闭了socket 文件描述符，其他进程的也会被关闭，但他关闭的时候只关闭一半，即发送数据通道关闭，接收数据还是可以的。如果对写 *** 作被关闭的socket执行写 *** 作会触发写就绪(EPOLLOUT)事件，同时触发一个SIGPIPE信号。
close的主要流程：

1）关闭监听句柄
先从最右边的分支说说关闭监听socket的那些事。用于listen的监听句柄也是使用close关闭，关闭这样的句柄含义当然很不同，它本身并不对应着某个TCP连接，但是，附着在它之上的却可能有半成品连接。什么意思呢？之前说过TCP是双工的，它的打开需要三次握手，三次握手也就是3个步骤，其含义为：客户端打开接收、发送的功能；服务器端认可并也打开接收、发送的功能；客户端认可。当第1、2步骤完成、第3步步骤未完成时，就会在服务器上有许多半连接，close这个 *** 作主要是清理这些连接。
参照上图，close首先会移除keepalive定时器。keepalive功能常用于服务器上，防止僵死、异常退出的客户端占用服务器连接资源。移除此定时器后，若ESTABLISH状态的TCP连接在tcp_keepalive_time时间（如服务器上常配置为2小时）内没有通讯，服务器就会主动关闭连接。
接下来，关闭每一个半连接。如何关闭半连接？这时当然不能发FIN包，即正常的四次握手关闭连接，而是会发送RST复位标志去关闭请求。处理完所有半打开的连接close的任务就基本完成了。
2）关闭普通ESTABLISH状态的连接（未设置so_linger）
首先检查是否有接收到却未处理的消息。
如果close调用时存在收到远端的、没有处理的消息，这时根据close这一行为的意义，是要丢弃这些消息的。但丢弃消息后，意味着连接远端误以为发出的消息已经被本机收到处理了（因为ACK包确认过了），但实际上确是收到未处理，此时也不能使用正常的四次握手关闭，而是会向远端发送一个RST非正常复位关闭连接。这个做法的依据请参考draft-ietf-tcpimpl-prob-03txt文档310节，Failure to RST on close with data pending。所以，这也要求我们程序员在关闭连接时，要确保已经接收、处理了连接上的消息。
如果此时没有未处理的消息，那么进入发送FIN来关闭连接的阶段。
这时，先看看是否有待发送的消息。前一篇已经说过，发消息时要计算滑动窗口、拥塞窗口、angle算法等，这些因素可能导致消息会延迟发送的。如果有待发送的消息，那么要尽力保证这些消息都发出去的。所以，会在最后一个报文中加入FIN标志，同时，关闭用于减少网络中小报文的angle算法，向连接对端发送消息。如果没有待发送的消息，则构造一个报文，仅含有FIN标志位，发送出去关闭连接。
3）使用了so_linger的连接
首先要澄清，为何要有so_linger这个功能？因为我们可能有强可靠性的需求，也就是说，必须确保发出的消息、FIN都被对方收到。例如，有些响应发出后调用close关闭连接，接下来就会关闭进程。如果close时发出的消息其实丢失在网络中了，那么，进程突然退出时连接上发出的RST就可能被对方收到，而且，之前丢失的消息不会有重发来保障可靠性了。
so_linger用来保证对方收到了close时发出的消息，即，至少需要对方通过发送ACK且到达本机。
怎么保证呢？等待！close会阻塞住进程，直到确认对方收到了消息再返回。然而，网络环境又得复杂的，如果对方总是不响应怎么办？所以还需要l_linger这个超时时间，控制close阻塞进程的最长时间。注意，务必慎用so_linger，它会在不经意间降低你程序中代码的执行速度（close的阻塞）。
所以，当这个进程设置了so_linger后，前半段依然没变化。检查是否有未读消息，若有则发RST关连接，不会触发等待。接下来检查是否有未发送的消息时与第2种情形一致，设好FIN后关闭angle算法发出。接下来，则会设置最大等待时间l_linger，然后开始将进程睡眠，直到确认对方收到后才会醒来，将控制权交还给用户进程。
这里需要注意，so_linger不是确保连接被四次握手关闭再使close返回，而只是保证我方发出的消息都已被对方收到。例如，若对方程序写的有问题，当它收到FIN进入CLOSE_WAIT状态，却一直不调用close发出FIN，此时，对方仍然会通过ACK确认，我方收到了ACK进入FIN_WAIT2状态，但没收到对方的FIN，我方的close调用却不会再阻塞，close直接返回，控制权交还用户进程。
从上图可知，so_linger还有个偏门的用法，若l_linger超时时间竟被设为0，则不会触发FIN包的发送，而是直接RST复位关闭连接。我个人认为，这种玩法确没多大用处。
最后做个总结。调用close时，可能导致发送RST复位关闭连接，例如有未读消息、打开so_linger但l_linger却为0、关闭监听句柄时半打开的连接。更多时会导致发FIN来四次握手关闭连接，但打开so_linger可能导致close阻塞住等待着对方的ACK表明收到了消息。
最后来看看较为简单的shutdown。
1）shutdown可携带一个参数，取值有3个，分别意味着：只关闭读、只关闭写、同时关闭读写。
对于监听句柄，如果参数为关闭写，显然没有任何意义。但关闭读从某方面来说是有意义的，例如不再接受新的连接。看看最右边蓝色分支，针对监听句柄，若参数为关闭写，则不做任何事；若为关闭读，则把端口上的半打开连接使用RST关闭，与close如出一辙。
2）若shutdown的是半打开的连接，则发出RST来关闭连接。
3）若shutdown的是正常连接，那么关闭读其实与对端是没有关系的。只要本机把接收掉的消息丢掉，其实就等价于关闭读了，并不一定非要对端关闭写的。实际上，shutdown正是这么干的。若参数中的标志位含有关闭读，只是标识下，当我们调用read等方法时这个标识就起作用了，会使进程读不到任何数据。
4）若参数中有标志位为关闭写，那么下面做的事与close是一致的：发出FIN包，告诉对方，本机不会再发消息了。
c语言socket关闭,如何在c语言下关闭socket_慕容圆月的博客
1、shutdown()在如何关闭套接字上有多一点的控制。shutdown 可以单向关闭,Close不可以。 2、当多线程共享/调用同一个Socket时,Close只是会减1,直到减到0才会真正去关闭Socket, 而shutdown则不会理会有多少线程在用,强制直接关闭sock
继续访问
socket关闭_mengfick的博客
时,意思是说,发送FIN的一端就不能发送数据,也就是关闭了其中一条数据通路。被动关闭的一端发送 了ACK后,应用层通常就会检测到这个连接即将断开,然后被动断开的应用层调用close关闭连接。 我可以告诉你,一旦当你调用close(or closesocke
继续访问
热门推荐 Socket的正确关闭(改良版)
TIME_WAIT状态 如果服务端的Socket比客户端的Socket先关闭，会导致客户端出现TIME_WAIT状态，占用系统资源。 所以，必须等客户端先关闭Socket后，服务器端再关闭Socket才能避免TIME_WAIT状态的出现。 判断客户端Socket的关闭 最近试验发现，当客户端Socket关闭时，服务端的Socket会接收到0字节的通知。 private int Receive(StringBuilder sb) { int read = 0, total
继续访问
socket连接建立与关闭
close函数 定义 close函数可以用于关闭套接字，并中只能TCP连接。 #include<unistdh> int close(int sockfd); close一个TCP套接字的默认行为是把该套接字标记为已关闭，然后立即返回到调用进程。该套接字不能再由调用进程使用，也就是说它不能再作为read或write等函数的第一个参数。 套接字发送缓冲区的数据将尝试被发送到对端，发
继续访问
关闭Socket_wkend的博客_js 关闭socket
当客户与服务器的通信结束,应该及时关闭Socket,已释放Socket占用的包括端口在内的各种资源。Socket的close()方法负责关闭Socket。当一个socket对象被关闭,就不能能在通过它的输入流和输出流进行I/O *** 作,否则会导致IOException。 为了确保
继续访问
socket链接的关闭close和shutdown的区别_TIME_WAIT和CLOSE_WAIT什么时刻出现_如何处理
TCP主动关闭连接 appl: close(), --> FIN FIN_WAIT_1 //主动关闭socket方，调用close关闭socket,发FIN //对方 *** 作系统的TCP层，给ACK响应。然后给FIN
继续访问
socket关闭
无论是服务端还是客户端,一旦有一方调用socketclose(),都表明此次通信终止,调用close会同时关闭输入输出 在回显例子,客户端知道接收完了数据,可以先调用close(),然后服务端再调用read将返回-1,表明服务端接收来自客户端的数据完成,然后服务端也可以调用close() 对于>关闭数据库连接 readtimeout 的具体方法可以因不同数据库而异。如果您使用的是 MySQL 数据库，您可以尝试以下方法：
1 登录到 MySQL 数据库的客户端。
2 执行 SHOW VARIABLES LIKE 'connect_timeout' 来检查当前连接超时设置的时间，如果需要更改，您可以执行 SET GLOBAL connect_timeout=30; 来将连接超时时间设置为 30 秒（可根据实际情况进行更改）。
3 执行 SHOW VARIABLES LIKE 'wait_timeout' 来检查当前等待连接超时设置的时间，如果需要更改，您可以执行 SET GLOBAL wait_timeout=28800; 将等待连接的超时时间设置为 8 小时（可根据实际情况进行更改）。
4 关闭数据库连接的具体方法可以因实现方式而异，但一般建议在使用完数据库连接后，及时将其关闭。您可以在代码中使用 close() 方法来手动关闭数据库连接，或者使用 try-with-resources 语句块，在语句块结束后自动关闭数据库连接。
请注意，关闭数据库连接需要遵循一定的约定和规则，否则可能导致未正常释放资源和造成内存泄漏等问题。因此，在进行关闭 *** 作时，建议您参考数据库文档和开发规范，并遵循最佳实践进行 *** 作。

在我们用客户端去连接云服务器或者实体服务器时，经常同时打开多台机器连接调试（特别是内网段跳转机器）。然而一般处于安全性考虑，服务器会判断客户端响应时长，对于超过一段时间未响应的客户端给予关闭连接的 *** 作，这本是很nice的设计，但实际 *** 作中，一些个人使用的云服务器机就不愿考虑那么多，希望一段时间后还能即开即用，以提高工作效率，我们可以尝试设置服务器端的响应时间。

意思是设置每60s服务端向客户端发送一个消息用以保持连接。
重启sshd服务：

#vim  /etc/profile

export TMOUT=300

若300秒内无输入，则退出当前bash 这个可以？

试了一下，远程和本机bash均退出了（偶使用的是vmware虚拟机做的）。暂时定为这个胜出吧！

但是这个是在客户端无发送请求包保持连接的情况下，若强制在服务器断开连接呢？得到这样的答案：

写个脚本   到2个小时就kill掉

弄脚本 干掉

#fuser -k /dev/pts/

#pkill -kill -t pts/

这两个应该都可以 干掉所有连接

但是试过都没成功，而且也没理解这命令的含义，所以就用我自己麻烦的办法kill了一下：

kill -9 `ps aux | grep ssh |grep @ |awk '{print $2}'`

在这里能用成。

另外，Xshell工具连接的：

服务器默认就是会断开的，但是连接工具会设置 发送活动状态；

在属性-连接-保持活动状态中，将会话期间保持活动状态前面框里，去掉这个勾选，就ok了！

---