linux read命令作用？

一、linux read命令作用？

1、linux系统中read命令用于从标准输入中读取数据，进而给变量赋值。

 2、直接使用read，不加变量名称，变量赋值给REPLY。

3、通过-p参数加入提示。

4、通过-t参数限制输入变量值的时间。

 5、通过-s 选项隐藏输入的变量值，比如在屏幕输入密码。

 6、通过-n参数实现限定输入变量的长度。

 7、使用-r参数限制为原始字符串

 8、从文件中读取变量值

二、socket read time out解决方法？

很明显，出现这种问题的原因是读取文件超时，解决方法是将HTTP Keep-Alive Timeout这个参数设置地尽量大，但是有没有更好的解决方法，由于使用的服务器是tomcat，便可以通过修改服务器配置来解决该问题

三、linux socket文件的作用？

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。

四、linux socket默认超时时间？

举例： s=socket(); 设置s为non-blocking； connect(s,..); FD_SET...; rc = select(..., 10s); if (rc == 0) 表示10s超时了。 这个超时的意思是：10s之内，select中所有socket的事件均未产生（如果至少有一个产生，则rc大于0) 注意：这个10s跟connect本身的超时机制完全无关，前者的设置不影响后者。

10s后select的返回，表明10s内connect还没成功，connect可能还在按自己的超时机制（例如慢启动）尝试重连（当然它最终也有个超时）。

至于connect本身的超时是否可以设置，可能各系统不一样。 顺便提醒：connect的socket必须是non-blocking类型，否则，connect会阻塞，也就没必要用select来检测是否连接成功。

另外，那个s要注册到write类型的fd中，即select的第3个参数中。

其他listen，recv什么的，完全类似（但listen，recv本身没有什么超时概念）。

只不过listen的和recv的socket，要注册到read的fd中。

五、linux read函数阻塞怎么排查？

要排查Linux中read函数阻塞的问题，可以采取以下步骤：

1. 检查文件描述符是否正确，确保read函数调用的文件描述符是有效的。

2. 检查文件是否处于阻塞模式。可以使用fcntl函数设置文件描述符为非阻塞模式，或者使用select/poll/epoll等函数进行非阻塞IO操作。

3. 检查是否有其他进程或线程持有文件锁，导致read函数阻塞。可以使用flock或fcntl函数查看文件锁状态。

4. 检查是否有信号中断了read函数调用。可以使用sigaction函数设置信号处理程序，或者使用sigprocmask函数阻塞特定信号。

5. 检查是否有其他资源竞争导致read函数阻塞，例如网络连接问题或者磁盘IO问题。可以使用网络调试工具或者磁盘IO监控工具进行排查。

6. 检查read函数的返回值，如果返回-1并且errno为EINTR，则表示read函数被信号中断，需要相应处理。

7. 如果以上步骤都没有解决问题，可以考虑使用strace或者gdb等工具进行调试，查看系统调用和堆栈信息，以进一步定位问题。

六、linux下socket编程中close（）函数？

只要不用close或fclose，不管把这个socket_fd值存到哪里，都可以使用。比如：

int socket_fd = socket(...);

int socket_x = socket_fd;

那么send(socket_x)和send(socket_fd)结果完全一致

七、socket read time out 重启服务器能否解决？

是可以解决的，先断开网络连接再重新联网试试。

八、linux用户线程read如何调用内核？

所有IO接口函数最终都是调用sys_ctrl实现！

九、linux下每个socket会占用多少内存？

net.ipv4.tcp_wmem = 4096 16384 4194304net.ipv4.tcp_rmem = 4096 87380 4194304就是说，每个tcp连接的socket，至少需要8k字节，那么对于8G内存的机器，如果不考虑swap等其他因素，最多支持并发100万个tcpsocket

十、Linux中本机和本机Socket通信会走网卡吗？

旗帜鲜明说观点，本机之间的Socket通信，有可能走网卡，剩下的全部不走网卡。

这是一道路由（IP Routing）题，所以这道题只和IP Routing有关，即TCP/IP协议栈的IP路由有关。

不走网卡的场景

场景1：服务器IP = 127.0.0.1

服务器IP =127.0.0.1，即IP包的目IP=127.0.0.1，那IP包的源IP地址是什么？

IP模块基于目的IP =127.0.0.1，查询路由表发现最佳路由的出口为虚拟接口（127.0.0.1），于是就用它（127.0.0.1）作为源IP，它距离目的地最近。这是操作系统默认行为，如果用户没有明确指定源IP地址，操作系统选择路由出接口（Exiting Interface）的IP地址。

既然IP包已经完成了封装，IP Routing按照路由查询结果进行发送，并进入Sending Queue，IP Routing有一个判断逻辑，如果IP包的目的IP == 本地接口IP，需要将Sending Queue的该IP包移入Receiving Queue，相当于发送线与接收线短接（loopback）。

然后该IP包按照IP路由提交给虚拟接口（127.0.0.1），IP包没有经过网卡。

场景2：服务器IP = 10.1.1.1，IP绑定一个硬件网卡

同上，由于用户没有指定源IP，系统默认使用10.1.1.1作为源IP。该IP包被IP Routing做了收发短接，IP包在IP Routing模块里即发生了收发，IP包不经过网卡。

场景3：服务器IP = 10.1.1.1（一块网卡），客户端10.1.1.2 （同机另一块网卡），开启多接口路由功能

服务器IP =10.1.1.1，即IP包的目IP=10.1.1.1，源IP = 10.1.1.2 （由用户明确指定）。操作系统开启了多个网络接口IP Routing功能，如下图所示：

此时主机是一台路由器，该IP包被IP Routing做了收发短接，IP包在IP Routing模块里即发生了收发，IP包不经过网卡。

走网卡的场景

场景4：服务器IP = 10.1.1.1（一块网卡），客户端10.1.1.2 （同机另一块网卡），关闭多接口路由功能。

这个场景非常容易让人迷惑，之所以容易迷惑，是因为尽管服务器有两块网卡，但是这两块网卡老死不相往来。如果没有其它网络设备的帮助，是无法通信的，因为两块网卡之间的路由功能已经关闭，如下图所示：

目的IP =10.1.1.1，按照正常查询路由表的决策，最优路由（10.1.1.1/32，匹配长度为32bit）的出接口为10.1.1.1接口，那么应该使用10.1.1.1接口的IP= 10.1.1.1作为源IP地址，但是这和客户端指定的IP = 10.1.1.2并不相同，很显然无法满足客户端的需求。

于是，在次优路由里看看是否有满足用户需求的路由条目，值得欣慰的是，确实有这么一条次优路由（10.1.1.0/24，匹配长度为24bit），这条路由对应的出接口为10.1.1.2，系统会使用该接口的IP =10.1.1.2 作为源IP地址，恰好满足客户的需求。

然后这个IP包完成封装，进入Sending Queue，接下来会发生什么？

有同学说，由于IP包的目的IP地址 = 10.1.1.1， 恰好满足上文的判断逻辑，收发短接，同样不会经过网卡，对吗？

不对！

上文说了，这两块网卡是两个平行世界的接口，所以上文的判断逻辑不再适用。在出接口10.1.1.2的平行世界里，本地只有自己一个接口，接口10.1.1.1并不存在。

所以，接下来的一切主机之间的通信，就仿佛是两个主机之间的通信。需要发ARP广播请求对方的MAC地址，ARP通过网卡到达交换机，然后交换机广播ARP，ARP请求到达10.1.1.1。

服务器10.1.1.1发送ARP回复，经过网卡到达交换机，然后再到达主机10.1.1.2。最后两个主机就可以通信了，整个通信过程都会经过网卡。

上文的Routing的开关，在Windows操作系统使用“Services.msc” 设置”Routing and Remote Access”完成，Linux系统应该也有对应的开关配置。