精华内容
下载资源
问答
  • 在各种网络异常情况的背后,TCP是怎么处理的?又是怎样把处理结果反馈给上层应用的?...各种不同步的状态,都是通过发送RST来恢复的,理解这些状况的关键在于理解何时产生RST,以及在各种状态下,对RST段如何处理

    在各种网络异常情况的背后,TCP是怎么处理的?又是怎样把处理结果反馈给上层应用的?本文就来讨论这个问题。分为两个场景来讨论

    建立连接时的异常情况

    1 正常情况下
      经过三次握手,客户端连接成功,服务端有一个新连接到来。
    在这里插入图片描述

    2 客户端连接了服务端未监听的端口
      在这种情况下,服务端会对收到的SYN回应一个RST(RFC 793 3.4),客户端收到RST之后,终止连接,并进入CLOSED状态。
    客户端的connect返回ECONNREFUSED 111 /* Connection refused */。
    在这里插入图片描述

    3 客户端与服务器之间的网络不通,这又分两种情况
      connect返回主机不可达。具体信息在不同系统上不一样,比如linux上的定义是EHOSTUNREACH 113 /* No route to host */。明显给出了一个不可访问的地址(例如,访问一个不存在的本地网络地址,或者DNS解析失败会导致这种情况。
    connect返回连接超时。这种情况下,客户端发送的SYN丢失在网络中,没有得到确认,客户端的TCP会超时重发SYN。以ubuntu 12.04为例,重发SYN的时间,系列是:0,1,3,7,15,31,63(2n-1-1)。即发送7个SYN后等待一个超时时间(例如:127秒),如果在这段时间内仍然没有收到ACK,则connect返回超时。
      在这两种情况下, 服务端的状态没有变化,对服务端来讲什么也没发生。

    4 建立连接的过程中包丢失
      三次握手发送的包系列是SYN > SYN-ACK > ACK
      SYN丢失。这种情况就是3种的第2种情况。
      SYN-ACK丢失。从客户端的角度来讲以前面一种情况类似。从服务端的角度来讲,由LISTEN状态进入SYN_REVD状态。服务端的TCP会重发SYN-ACK,直到超
    时。SYN攻击正是利用这一原理,攻击方伪造大量的SYN包发送到服务器,服务器对收到的SYN包不断回应SYN-ACK,直到超时。这会浪费服务
    器大量的资源,甚至导致奔溃。对服务端的应用层来讲,什么也没有发生。因为TCP只有在经过3次握手之后才回通知应用层,有新的连接到来。
    在这里插入图片描述

    ACK丢失。这对服务端来讲与2相同。对于客户端来讲,由SYN_SENT状态进入了ESTABLISED状态,即连接成功了。连接成功后客户端就可以发送数据了。
    但实际上数据是发送不到服务端的(我们假设客户端收到SYN-ACK之后,客户端与服务端之间的网络就断开了),客户端发送出去的数据得不
    到确认,一般重发3次左右就会处于等待ACK的状态(win7)。而ubuntu 12.10下,调用send会返回成功,直到TCP的缓冲被填满(测试环
    境:局域网,感觉这个不是很合理,按照书上所说:应该是使用“指数退避”进行重传 – TCP/IP协议详解, 大概是我的测试环境中有NAT所致
    吧)。最终,客户端产生一个复位信号并终止连接。返回给应用程序的结果是Connection time out(errno: 110)

    连接建立成功后出现的异常情况
    1 客户端与服务器的网络断开,双方不再发送数据
      这样,双方都不知道网络已经不通,会一直保持ESTABLISHDED状态,除非打开了SO_KEEPALIVE选项。

    2 网络断开,一方给另一方发送数据
      这种情况下,接收一方不知道网络出问题,会一直等待数据到来。对于发送方,理论上的情况是,重传一定次数后,返回连接超时。不过实际,很可能是这样的情况,发送方显示发送数据成功(send返回发送的数据长度),但实际接收方还没有接收到数据。
      对于已经发送成功的数据有3种可能情况:
        1 在本机的TCP缓存中
        2 在网络上的某个NAT的缓存中
        3 对方已经成功接收到
      在实验的过程中发现,即使网络断开了,发送方仍然收到了对数据的ACK(在有NAT的情况下),猜测是NAT把数据缓存起来并发送了ACK。
      当网络恢复时,那些被缓存的数据会被发送到接收方。鉴于这样的结果,给我们一个提示:不能依赖于TCP的可靠性,认为我发送成功的数据,对方一
    定能收到。TCP可以保证可靠、有序的传输,这意思是说保证收到的数据时有序正确的,并没有说已经发送成功的数据,对方一定就收到了。
      在ubuntu 12.10上,发送方一直在发送数据,直到缓冲区满。而在win7下,重发3次就会停止,进入等待ACK状态。
    解决的办法是:应用层对数据是否接收完成进行确认(需要的时候)。

    3 网络断开,一方等待着另一方发送数据
      这种情况下,等待数据的一方将一直等待下去。接收方无法直接知道网络已经断开,一般是设置一个超时时间,超时时间到就判断为网络已断开。发送
    数据的一方的反应如2所述。

    4 一方crash,另一方继续发送/接收数据
      这依赖于TCP协议栈对crash的反应。与系统相关性很大,例如:
        在windows下:按ctrl+c结束程序,会发送RST段。而在linux下,按ctrl+c结束程序,会调用close。
        在wind7下,如果没有调用close而结束程序,TCP会发送RST。而Ubuntu12.10上,则会发送FIN段。

    1.crash的一端发送FIN,相当于调用了close
        没有crash的一端接收数据,具体的反应与系统有关,例如
          linux 3.8.0-29-generic调用recv返回-1,errno被设置为22,Invalid argument,而linux3.3.6-030306-generic调用recv返回0.在TCP内部,调用recv时,发送FIN,终止连接(Linux)。
          windows情况以此不同,recv返回0,表示对方调用了shutdown。TCP内部发送一个RST。
        但共同点是recv都会立即返回失败。

    没有crash的一端发送数据
          第一次调用send返回成功,数据会被发送到crash的一端,crash的一端会回应一个RST,再次调用send返回-1, errno被设置为32, Broken pipe。 注意:这会向应用程序发送SIGPIPE信号,你的程序会莫名其妙退出。这是因为程序对SIGPIPE的默认处理就是结束程序。
          这是编写服务器程序是最需要注意的一个问题。最简单的处理方法是忽略该信号 – signal(SIGPIPE,SIG_IGN);
    windows下行为是一样的, 不同的是返回的错误是10053 - WSAECONNABORTED, 由于软件错误,造成一个已经建立的连接被取消。
        共同点第一次send成功,之后就出错。

    2.crash的一端发送RST
        没有crash的一端接收数据
          调用recv返回-1,errno被设置为104, Connection reset by peer。在TCP内部,当收到RST时,把错误号设为ECONNRESET。
        没有crash的一端发送数据
          调用send返回-1,errno被设置为104, Connection reset by peer。在TCP内部,当收到RST时,把错误号设为ECONNRESET

    3.crash的一端即没发送FIN也没发送RST
        没有crash的一端接收数据
          调用recv会一直阻塞等待数据到来
        没有crash的一端发送数据
          重传一定次数后,返回connection time out。

    5 一端关闭连接
      这种情况与一端crash并发送FIN 的情况相同,参看4.1

    总结
      上面分析的目的是:当程序出现网络异常时,能够知道问题的原因在哪?

    作为开发者,我们主要关心应用层面的返回状态。一般出错的地方是调用connect, recv, send的时候。
      下面做一个总结
        connect函数返回状态及其原因
    在这里插入图片描述

    recv函数返回状态及其原因
    在这里插入图片描述

    send函数返回状态及其原因
    在这里插入图片描述

    各种不同步的状态,都是通过发送RST来恢复的,理解这些状况的关键在于理解何时产生RST,以及在各种状态下,对RST段如何处理

    展开全文
  • 各种不同步的状态,都是通过发送RST来恢复的,理解这些状况的关键在于理解何时产生RST,以及在各种状态下,对RST段如何处理。   转自:http://www.360doc.com/content/16/1221/10/39271878_616489424.shtml

    在各种网络异常情况的背后,TCP是怎么处理的?又是怎样把处理结果反馈给上层应用的?本文就来讨论这个问题。分为两个场景来讨论

    建立连接时的异常情况

    1 正常情况下
      经过三次握手,客户端连接成功,服务端有一个新连接到来。

     

    2 客户端连接了服务端未监听的端口
      在这种情况下,服务端会对收到的SYN回应一个RST(RFC 793 3.4),客户端收到RST之后,终止连接,并进入CLOSED状态。
    客户端的connect返回ECONNREFUSED 111 /* Connection refused */。


    3 客户端与服务器之间的网络不通,这又分两种情况
      connect返回主机不可达。具体信息在不同系统上不一样,比如linux上的定义是EHOSTUNREACH 113 /* No route to host */。明显给出了一个不可访问的地址(例如,访问一个不存在的本地网络地址,或者DNS解析失败会导致这种情况。
    connect返回连接超时。这种情况下,客户端发送的SYN丢失在网络中,没有得到确认,客户端的TCP会超时重发SYN。以ubuntu 12.04为例,重发SYN的时间,系列是:0,1,3,7,15,31,63(2n-1-1)。即发送7个SYN后等待一个超时时间(例如:127秒),如果在这段时间内仍然没有收到ACK,则connect返回超时。
      在这两种情况下, 服务端的状态没有变化,对服务端来讲什么也没发生。

    4 建立连接的过程中包丢失
      三次握手发送的包系列是SYN > SYN-ACK > ACK
      SYN丢失。这种情况就是3种的第2种情况。
      SYN-ACK丢失。从客户端的角度来讲以前面一种情况类似。从服务端的角度来讲,由LISTEN状态进入SYN_REVD状态。服务端的TCP会重发SYN-ACK,直到超
    时。SYN攻击正是利用这一原理,攻击方伪造大量的SYN包发送到服务器,服务器对收到的SYN包不断回应SYN-ACK,直到超时。这会浪费服务
    器大量的资源,甚至导致奔溃。对服务端的应用层来讲,什么也没有发生。因为TCP只有在经过3次握手之后才回通知应用层,有新的连接到来。


      ACK丢失。这对服务端来讲与2相同。对于客户端来讲,由SYN_SENT状态进入了ESTABLISED状态,即连接成功了。连接成功后客户端就可以发送数据了。
    但实际上数据是发送不到服务端的(我们假设客户端收到SYN-ACK之后,客户端与服务端之间的网络就断开了),客户端发送出去的数据得不
    到确认,一般重发3次左右就会处于等待ACK的状态(win7)。而ubuntu 12.10下,调用send会返回成功,直到TCP的缓冲被填满(测试环
    境:局域网,感觉这个不是很合理,按照书上所说:应该是使用“指数退避”进行重传 -- TCP/IP协议详解, 大概是我的测试环境中有NAT所致
    吧)。最终,客户端产生一个复位信号并终止连接。返回给应用程序的结果是Connection time out(errno: 110)

     

    连接建立成功后出现的异常情况
    1 客户端与服务器的网络断开,双方不再发送数据
      这样,双方都不知道网络已经不通,会一直保持ESTABLISHDED状态,除非打开了SO_KEEPALIVE选项。

    2 网络断开,一方给另一方发送数据
      这种情况下,接收一方不知道网络出问题,会一直等待数据到来。对于发送方,理论上的情况是,重传一定次数后,返回连接超时。不过实际,很可能是这样的情况,发送方显示发送数据成功(send返回发送的数据长度),但实际接收方还没有接收到数据。
      对于已经发送成功的数据有3种可能情况:
        1 在本机的TCP缓存中
        2 在网络上的某个NAT的缓存中
        3 对方已经成功接收到
      在实验的过程中发现,即使网络断开了,发送方仍然收到了对数据的ACK(在有NAT的情况下),猜测是NAT把数据缓存起来并发送了ACK。
      当网络恢复时,那些被缓存的数据会被发送到接收方。鉴于这样的结果,给我们一个提示:不能依赖于TCP的可靠性,认为我发送成功的数据,对方一
    定能收到。TCP可以保证可靠、有序的传输,这意思是说保证收到的数据时有序正确的,并没有说已经发送成功的数据,对方一定就收到了。
      在ubuntu 12.10上,发送方一直在发送数据,直到缓冲区满。而在win7下,重发3次就会停止,进入等待ACK状态。
    解决的办法是:应用层对数据是否接收完成进行确认(需要的时候)。

    3 网络断开,一方等待着另一方发送数据
      这种情况下,等待数据的一方将一直等待下去。接收方无法直接知道网络已经断开,一般是设置一个超时时间,超时时间到就判断为网络已断开。发送
    数据的一方的反应如2所述。

    4 一方crash,另一方继续发送/接收数据
      这依赖于TCP协议栈对crash的反应。与系统相关性很大,例如:
        在windows下:按ctrl+c结束程序,会发送RST段。而在linux下,按ctrl+c结束程序,会调用close。
        在wind7下,如果没有调用close而结束程序,TCP会发送RST。而Ubuntu12.10上,则会发送FIN段。

      1.crash的一端发送FIN,相当于调用了close
        没有crash的一端接收数据,具体的反应与系统有关,例如
          linux 3.8.0-29-generic调用recv返回-1,errno被设置为22,Invalid argument,而linux3.3.6-030306-generic调用recv返回0.在TCP内部,调用recv时,发送FIN,终止连接(Linux)。
          windows情况以此不同,recv返回0,表示对方调用了shutdown。TCP内部发送一个RST。
        但共同点是recv都会立即返回失败。

        没有crash的一端发送数据
          第一次调用send返回成功,数据会被发送到crash的一端,crash的一端会回应一个RST,再次调用send返回-1, errno被设置为32, Broken pipe。 注意:这会向应用程序发送SIGPIPE信号,你的程序会莫名其妙退出。这是因为程序对SIGPIPE的默认处理就是结束程序。
          这是编写服务器程序是最需要注意的一个问题。最简单的处理方法是忽略该信号 -- signal(SIGPIPE,SIG_IGN);
    windows下行为是一样的, 不同的是返回的错误是10053 - WSAECONNABORTED, 由于软件错误,造成一个已经建立的连接被取消。
        共同点第一次send成功,之后就出错。

      2.crash的一端发送RST
        没有crash的一端接收数据
          调用recv返回-1,errno被设置为104, Connection reset by peer。在TCP内部,当收到RST时,把错误号设为ECONNRESET。
        没有crash的一端发送数据
          调用send返回-1,errno被设置为104, Connection reset by peer。在TCP内部,当收到RST时,把错误号设为ECONNRESET

      3.crash的一端即没发送FIN也没发送RST
        没有crash的一端接收数据
          调用recv会一直阻塞等待数据到来
        没有crash的一端发送数据
          重传一定次数后,返回connection time out。

    5 一端关闭连接
      这种情况与一端crash并发送FIN 的情况相同,参看4.1

    总结
      上面分析的目的是:当程序出现网络异常时,能够知道问题的原因在哪?

      作为开发者,我们主要关心应用层面的返回状态。一般出错的地方是调用connect, recv, send的时候。
      下面做一个总结
        connect函数返回状态及其原因

        recv函数返回状态及其原因

        send函数返回状态及其原因

      各种不同步的状态,都是通过发送RST来恢复的,理解这些状况的关键在于理解何时产生RST,以及在各种状态下,对RST段如何处理。

     

    转自:http://www.360doc.com/content/16/1221/10/39271878_616489424.shtml

    展开全文
  • 深入理解socket

    2017-12-26 12:46:20
    Linux提供了创建socket的一个系统调用,通过该系统调用,能够得到一个用来访问套接字的描述符:  #include  #include  int socket( int domain, int type, int protocol );  内核中的系统调

          一个socket代表了通信链路的一端,存储或指向与链路有关的所有信息。Linux提供了创建socket的一个系统调用,通过该系统调用,能够得到一个用来访问套接字的描述符:
             #include <sys/types.h>
             #include <sys/socket.h>
             int socket( int domain, int type, int protocol );
          内核中的系统调用函数原型是在net/socket.c 1180行:
             asmlinkage long sys_socket( int family, int type, int protocol );
          该函数主要做了两件事情:创建一个代表通讯端点的结构体struct socket,将这个结构映射到一个文件描述符上,最后将这个描述符返回,也就是我们调用socket得到的套接字描述符。
     下面是Linux内核中对结构socket的定义(不同操作系统间,对该结构的定义会有差异):
     struct socket {
         socket_state            state;
         unsigned long           flags;
         struct proto_ops        *ops;
         struct fasync_struct    *fasync_list;
         struct file             *file;
         struct sock             *sk;
         wait_queue_head_t       wait;
         short                   type;
     };
             
           state是一个内部状态标志:
           typedef enum {
               SS_FREE = 0,         /* 未分配 */
               SS_UNCONNECTED,      /* 未连接 */
               SS_CONNECTING,       /* 正在连接当中 */
               SS_CONNECTED,        /* 已经连向一个套接字 */
               SS_DISCONNECTING     /* 正在断开连接 */
           } socket_state;

          flags也是一个标志,下面是它的取值:
          #define SOCK_ASYNC_NOSPACE 0
          #define SOCK_ASYNC_WAITDATA 1
          #define SOCK_NOSPACE  2
          #define SOCK_PASSCRED  3            ops是协议相关的一系例操作的集合,包括listen, bind, connect等常用socket操作,struct proto_ops结构体在include/linux/net.h 123行。            fasync_list是一个异步唤醒的列表,结构体struct fasync_struct在include/linux/fs.h 733行            sk是一个网络层的套接字表示,关于结构体struct sock,下文会有专门介绍。      type是套接字的类型:
          enum sock_type {
               SOCK_STREAM = 1,        /*可靠字节流服务套接字,TCP*/
               SOCK_DGRAM = 2,  /*传输层数据报服务, UDP*/
               SOCK_RAW = 3,  /*网络层数据报服务, ICMP, IGMP,  原始IP*/
               SOCK_RDM = 4,  /*可靠的数据报服务*/
               SOCK_SEQPACKET = 5, /*可靠的双向记录流服务*/
               SOCK_PACKET = 10,  /*已废弃*/
          };
     
          暂时放一下struct sock,先来看看sys_socket的第一步创建struct socket中究竟做了些什么(描述越过了一些不是很重要的步骤):
          首先,检查传入的用来标识域的协议族变量family是否在合法范围内,关于family,我们只关心其中的几个值,PF_INET表示因特网协议,PF_UNIX是unix文件系统套接字。
          然后,对于(family == PF_INET && type == SOCK_PACKET )的情况,因为是已废弃的,给出警告信息。
          net_families是一个数组,所有的协议族都在这个数组中注册,数组的项是一个结构体:
          struct net_proto_family {
               int  family;
               int  (*create)(struct socket *sock, int protocol);
               short  authentication;
               short  encryption;
               short  encrypt_net;
               struct module *owner;
          };
           对于我们要创建的family,我们必须确保能在这个数组中找到相应的项(即内核支持该域)。
           在内存中创建一个struct socket,并将其type赋值为传入的type值。
           调用net_families[family]->create完成最后的创建工作。返回。
           至此,一个socket就创建成功了。但还有两个问题没有明确:struct sock结构体的内容,以及net_families[family]->create如何完成对socket的创建。下一篇将结合inet域的实际例子进行分析。
    展开全文
  • 深入理解Socket的读写

    万次阅读 2020-03-10 20:25:36
    前言 对于Linux网络编程,有很多坑需要我们去踩。在这个时候,我们才会知道理论知识的重要性。无论是哪种语言,网络编程都可以写成厚厚的一本...深入理解write 首先,我们来解决上面的问题。为什么网络断了,还能wri...

    前言

    对于Linux网络编程,有很多坑需要我们去踩。在这个时候,我们才会知道理论知识的重要性。无论是哪种语言,网络编程都可以写成厚厚的一本书。举个例子,比如“当网络断掉,我们调用write去往socket中写入数据,为什么返回正常写入呢?”。所以有空多看看《TCP/IP详解》,《UNIX网络编程》等经典书籍来补充网络知识。

    深入理解write

    首先,我们来解决上面的问题。为什么网络断了,还能write还是返回成功呢?我们先看write的定义:

    #include <unistd.h>
    ssize_t write(int fd, const void *buf, size_t count);
    

    对于write的返回值,它表示写入的字节数。而这个写入,是写到哪呢?是成功发送的意思吗? 其实并不是,write成功返回,只是buf中的数据被复制到了kernel中的TCP发送缓冲区。至于数据什么时候被发往网络,系统调用层面不会给予任何保证和通知。

    所以,我们并不能直接根据write的返回值来判定发送成功,这也就是为什么网络断掉了,write的返回值和我们希望写入的值是一样的。

    阻塞和非阻塞

    读写操作肯定会涉及阻塞和非阻塞的问题。那write和read在什么情况下会阻塞呢?当kernel中该socket的发送缓冲区已满时write会阻塞。而read调用阻塞,通常是发送端的数据没有到达。

    对于每个socket,拥有自己的发送缓冲区和接收缓冲区。两个缓冲区大小都由系统来自动调节,但一般在default和max之间浮动。
    在这里插入图片描述
    默认socket是阻塞的,将一个socket 设置成非阻塞模式,可以使用fcntl方法:

    int flags;
    if ((flags = fcntl(fd, F_GETFL, NULL)) < 0) {
        return -1;
    }
    if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) {
        return -1;
    }
    

    阻塞(默认)和非阻塞模式下read/write行为的区别:

    1. read总是在接收缓冲区有数据时立即返回,而不是等到给定的read buffer填满时返回。只有当接收缓冲区为空时,阻塞模式才会等待,而非阻塞模式下会立即返回-1。

    2. 阻塞的write只有在缓冲区足以放下整个buffer时才返回。非阻塞write则是返回能够放下的字节数,之后调用则返回-1。

    对于阻塞的write有个特殊情况:

    当write阻塞等待时,对端关闭了socket,则write则会立即将剩余缓冲区填满并返回所写的字节数,再次调用write则会失败。

    更多精彩文章,欢迎关注"嵌入式软件开发交流"

    欢迎大家关注我的微信公众号!!
    展开全文
  • socket起源于Unix,而Unix/Linux基本哲学之一就是“一切皆文件”,都可以用“打开open –> 读写write/read –> 关闭close”模式来操作。Socket就是该模式的一个实现, socket即是一种特殊的文件,一些socket...
  • 下面我们深入理解一下socket到底是什么。     我们回忆一下socket编程的步骤,不管是客户端还是服务端,第一个调的函数都是socket。我们就从这个函数的实现开始,看看一个socket到底是什么。 //...
  • 下面我们深入理解一下socket到底是什么。 我们回忆一下socket编程的步骤,不管是客户端还是服务端,第一个调的函数都是socket。我们就从这个函数的实现开始,看看一个socket到底是什么。// 新建一个socket结构体,...
  • Socket深入理解之一

    千次阅读 2017-09-27 12:34:06
    Socket本质上还是文件,因为Linux上一切皆文件。Socket也有对应的文件描述符(fd)。文件描述符相关的参考另外一篇博客。在这里简单就认为,它是对应着一个文件的,就可以。 Socket位于TCP/IP之上,通过Socket...
  • 目前linux网络API是基于BSD套接口的(系统V提供基于流I/O子系统的用户接口,但是linux内核目前不支持流I/O子系统)。套接口可以说是网络编程中一个非常重要的概念,linux以文件的形式实现套接口,与套接口相应的文件...
  • 深入理解linux应用 Linux进程间通信方式 环境: 平台 内核版本 安卓版本 RK3399 Linux4.4 Android7.1 文章目录1、Linux进程间通信方式1.1、管道(Pipe)和命名管道(FIFO)1.2、消息队列(Message Queue...
  • 而很多时候,如果你对Linux底层的理解不深的话,遇到很多线上性能瓶颈你会觉得狗拿刺猬,无从下手。 我们今天用图解的方式,来深度理解一下在Linux下网络包的接收过程。还是按照惯例来借用一段最简单的代码开始思考...
  • 1,ls -l深入理解 total 8196:当前路径下所有文件的大小,以KB为单位 -rwxrwxr-x 1 gec gec 7260 Jul 17 23:27 alloc -:文件类型: linux七大类文件: -:普通文件 d:目录文件 l:软链接文件(windows...
  • linux socket 聊天室

    2019-10-09 00:43:28
    基于socket的聊天室早在开学初就有做过类似的,只不过当时用的java来实现,而且因为没有正式学过socket,代码只是搬用别人的,并没有深入理解。 单用户-服务的对话还是很好实现的,即使是多用户-服务,只要不是连续...
  • IO模型 IO模型就是说用什么样的通道进行数据的发送和接收,Java共支持3种网络编程IO模式:BIO,NIO,AIO BIO(Blocking IO) 同步阻塞模型,一个客户端...import java.net.Socket; public class SocketServer {
  • linuxsocket编程

    2011-02-18 11:41:56
    在Java里面进行socket编程是很容易的事情,为了更好地搞清楚socket运行机制,有必要了解一下linuxsocket是如何运行的。由于涉及到底层的东西比较多,即使你本来很了解如何运用这些API,但究其下面层次的原理,如果...
  • Linux Socket CAN驱动 ...为了能够对Socket CAN的深入理解,我们需要了解Socket的机制。  Socket的中文翻译为“插座”,在计算机世界里称为套接字。Socket最初是作为网络上不同主机之间进程的
  • Linux Socket编程实战第1季第1部分

    千人学习 2018-01-22 21:49:43
    课程特点: 1、手把手的实际操作过程; 2、引导学员一步步去思考; 3、网络技术方面初级的一步步进入linux socket编程的世界; 本课程是linux socket编程的一小部分,从无名套...理解linux socket编程的技巧和方法。
  • 分析完了服务器端,我们继续分析客户端,在socket编程中,客户端的流程是比较简单的,申请一个socket,然后调connect去发起连接就行。我们先看一下connect函数的定义。 /* socket 通过socket函数申请的结构体 ...
  • 概述: ... 用户空间与内核有多种交互方式,最常用的有以下四种:通过/proc虚拟文件系统,通过/sys虚拟文件系统,通过ioctl系统调用,通过Netlink socket。 其中编写程序时最常使用ioctl,这四种方式...
  • 按照socket网络编程的顺序,我们这一篇来分析bind函数。我们通过socket函数拿到了一个socket结构体。bind函数的逻辑其实比较简单,他就是给socket结构体绑定一个地址,简单来说,就是给他的某些字段赋值。talk is ...
  • 很多同学都了解三次握手是什么,但是可能很少同学会深入思考或者看他的实现,众所周知,一个服务器启动的时候,会监听一个端口。其实就是新建了一个socket。那么如果有一个连接到来的时候,我们通过accept就能拿到这...
  • linux下的进程通信手段基本上是从Unix平台上的进程通信手段继承而来的。而对Unix发展做出重大贡献的两大主力AT&T的贝尔实验室及BSD(加州大学伯克利分校的伯克利软件发布中心)在进程间通信方面的侧重点有所不同。...

空空如也

空空如也

1 2 3 4 5 6
收藏数 118
精华内容 47
关键字:

linux深入理解socket

linux 订阅