zoukankan      html  css  js  c++  java
  • python--8、socket网络编程

    socket

    socket可以完成C/S架构软件的开发。
    须知一个完整的计算机系统是由硬件、操作系统、应用软件三者组成,具备了这三个条件,一台计算机就可以工作了。但是要跟别人一起玩,就要上互联网(互联网的本质就是一系列的网络协议)。

    互联网的核心就是由一堆协议组成,协议就是标准,比如全世界人通信的标准是英语。所有的计算机都学会了互联网协议,那所有的计算机都就可以按照统一的标准去收发信息从而完成通信了。
    互联网协议的功能:定义计算机如何接入internet,以及接入internet的计算机通信的标准。

    OSI七层模型:

    • 应用层
    • 表示层
    • 会话层
    • 传输层
    • 网络层
    • 数据链路层
    • 物理层

    image

    物理层功能:

    主要是基于电器特性发送高低电压(电信号),高电压对应数字1,低电压对应数字0

    数据链路层的功能:

    定义了电信号的分组方式

    以太网协议:

    早期的时候各个公司都有自己的分组方式,后来形成了统一的标准,即以太网协议ethernet

    ethernet规定

    一组电信号构成一个数据包,叫做‘帧’ 每一数据帧分成:报头head和数据data两部分 head   data

    head包含:(固定18个字节)

    发送者/源地址,6个字节 接收者/目标地址,6个字节 数据类型,6个字节 data包含:(最短46字节,最长1500字节)

    数据包的具体内容 head长度+data长度=最短64字节,最长1518字节,超过最大限制就分片发送

    mac地址:

    head中包含的源和目标地址由来:ethernet规定接入internet的设备都必须具备网卡,发送端和接收端的地址便是指网卡的地址,即mac地址

    mac地址:每块网卡出厂时都被烧制上一个世界唯一的mac地址,长度为48位2进制,通常由12位16进制数表示(前六位是厂商编号,后六位是流水线号)

    广播:

    有了mac地址,同一网络内的两台主机就可以通信了(一台主机通过arp协议获取另外一台主机的mac地址)

    ethernet采用最原始的方式,广播的方式进行通信,即计算机通信基本靠吼 image

    网络层

    世界范围的互联网是由一个个彼此隔离的小的局域网组成的(一个局域网=一个广播域,跨广播域要通过路由转发)
    网络层功能:引入一套新的地址用来区分不同的广播域/子网,这套地址即网络地址

    IP协议:

    规定网络地址的协议叫ip协议,它定义的地址称之为ip地址,广泛采用的v4版本即ipv4,它规定网络地址由32位2进制表示
    范围0.0.0.0-255.255.255.255
    一个ip地址通常写成四段十进制数,例:172.16.10.1 ip地址分成两部分

    • 网络部分:标识子网
    • 主机部分:标识主机
      注意:单纯的ip地址段只是标识了ip地址的种类,从网络部分或主机部分都无法辨识一个ip所处的子网

    例:172.16.10.1与172.16.10.2并不能确定二者处于同一子网

    子网掩码

    所谓”子网掩码”,就是表示子网络特征的一个参数。它在形式上等同于IP地址,也是一个32位二进制数字,它的网络部分全部为1,主机部分全部为0。比如,IP地址172.16.10.1,如果已知网络部分是前24位,主机部分是后8位,那么子网络掩码就是11111111.11111111.11111111.00000000,写成十进制就是255.255.255.0。

    知道”子网掩码”,我们就能判断,任意两个IP地址是否处在同一个子网络。方法是将两个IP地址与子网掩码分别进行AND运算(两个数位都为1,运算结果为1,否则为0),然后比较结果是否相同,如果是的话,就表明它们在同一个子网络中,否则就不是。
    比如,已知IP地址172.16.10.1和172.16.10.2的子网掩码都是255.255.255.0,请问它们是否在同一个子网络?两者与子网掩码分别进行AND运算,

    172.16.10.1:10101100.00010000.00001010.000000001

    255255.255.255.0:11111111.11111111.11111111.00000000

    AND运算得网络地址结果:10101100.00010000.00001010.000000001->172.16.10.0

    172.16.10.2:10101100.00010000.00001010.000000010

    255255.255.255.0:11111111.11111111.11111111.00000000

    AND运算得网络地址结果:10101100.00010000.00001010.000000001->172.16.10.0

    结果都是172.16.10.0,因此它们在同一个子网络。

    总结一下,IP协议的作用主要有两个,一个是为每一台计算机分配IP地址,另一个是确定哪些地址在同一个子网络。

    ip数据包

    ip数据包也分为head和data部分,无须为ip包定义单独的栏位,直接放入以太网包的data部分

    head:长度为20到60字节

    data:最长为65,515字节。

    而以太网数据包的”数据”部分,最长只有1500字节。因此,如果IP数据包超过了1500字节,它就需要分割成几个以太网数据包,分开发送了。

    以太网头   ip 头   ip数据

    ARP协议

    arp协议由来:计算机通信基本靠吼,即广播的方式,所有上层的包到最后都要封装上以太网头,然后通过以太网协议发送,在谈及以太网协议时候,我门了解到

    通信是基于mac的广播方式实现,计算机在发包时,获取自身的mac是容易的,如何获取目标主机的mac,就需要通过arp协议

    arp协议功能:广播的方式发送数据包,获取目标主机的mac地址

    协议工作方式:每台主机ip都是已知的

    例如:主机172.16.10.10/24访问172.16.10.11/24

    一:首先通过ip地址和子网掩码区分出自己所处的子网

    场景   数据包地址
    同一子网 目标主机mac,目标主机ip
    不同子网 网关mac,目标主机ip

    二:分析172.16.10.10/24与172.16.10.11/24处于同一网络(如果不是同一网络,那么下表中目标ip为172.16.10.1,通过arp获取的是网关的mac)

    源mac	目标mac	源ip	目标ip	数据部分

    发送端主机 发送端mac FF:FF:FF:FF:FF:FF 172.16.10.10/24 172.16.10.11/24 数据

    三:这个包会以广播的方式在发送端所处的自网内传输,所有主机接收后拆开包,发现目标ip为自己的,就响应,返回自己的mac

     

    socket()模块函数用法

    复制代码
     1 import socket
     2 socket.socket(socket_family,socket_type,protocal=0)
     3 socket_family 可以是 AF_UNIX 或 AF_INET。socket_type 可以是 SOCK_STREAM 或 SOCK_DGRAM。protocol 一般不填,默认值为 0。
     4 
     5 获取tcp/ip套接字
     6 tcpSock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
     7 
     8 获取udp/ip套接字
     9 udpSock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    10 
    11 由于 socket 模块中有太多的属性。我们在这里破例使用了'from module import *'语句。使用 'from socket import *',我们就把 socket 模块里的所有属性都带到我们的命名空间里了,这样能 大幅减短我们的代码。
    12 例如tcpSock = socket(AF_INET, SOCK_STREAM)
    复制代码
    服务端套接字函数
    s.bind() 绑定(主机,端口号)到套接字
    s.listen() 开始TCP监听
    s.accept() 被动接受TCP客户的连接,(阻塞式)等待连接的到来

    客户端套接字函数
    s.connect() 主动初始化TCP服务器连接
    s.connect_ex() connect()函数的扩展版本,出错时返回出错码,而不是抛出异常

    公共用途的套接字函数
    s.recv() 接收TCP数据
    s.send() 发送TCP数据(send在待发送数据量大于己端缓存区剩余空间时,数据丢失,不会发完)
    s.sendall() 发送完整的TCP数据(本质就是循环调用send,sendall在待发送数据量大于己端缓存区剩余空间时,数据不丢失,循环调用send直到发完)
    s.recvfrom() 接收UDP数据
    s.sendto() 发送UDP数据
    s.getpeername() 连接到当前套接字的远端的地址
    s.getsockname() 当前套接字的地址
    s.getsockopt() 返回指定套接字的参数
    s.setsockopt() 设置指定套接字的参数
    s.close() 关闭套接字

    面向锁的套接字方法
    s.setblocking() 设置套接字的阻塞与非阻塞模式
    s.settimeout() 设置阻塞套接字操作的超时时间
    s.gettimeout() 得到阻塞套接字操作的超时时间

    面向文件的套接字的函数
    s.fileno() 套接字的文件描述符
    s.makefile() 创建一个与该套接字相关的文件

    服务端:

    #创建一个连接 socket.socket(AF_INET,SOCK_STREAM)

     

    基于TCP的socket

    tcp是基于链接的,必须先启动服务端,然后再启动客户端去链接服务端

    tcp服务端

    复制代码
    1 ss = socket() #创建服务器套接字
    2 ss.bind()      #把地址绑定到套接字
    3 ss.listen()      #监听链接
    4 inf_loop:      #服务器无限循环
    5     cs = ss.accept() #接受客户端链接
    6     comm_loop:         #通讯循环
    7         cs.recv()/cs.send() #对话(接收与发送)
    8     cs.close()    #关闭客户端套接字
    9 ss.close()        #关闭服务器套接字(可选)
    复制代码

    tcp客户端

    1 cs = socket()    # 创建客户套接字
    2 cs.connect()    # 尝试连接服务器
    3 comm_loop:        # 通讯循环
    4     cs.send()/cs.recv()    # 对话(发送/接收)
    5 cs.close()            # 关闭客户套接字

     

    粘包

    须知:只有TCP有粘包现象,UDP永远不会粘包,为何,且听我娓娓道来

    首先需要掌握一个socket收发消息的原理

    发送端可以是一K一K地发送数据,而接收端的应用程序可以两K两K地提走数据,当然也有可能一次提走3K或6K数据,或者一次只提走几个字节的数据,也就是说,应用程序所看到的数据是一个整体,或说是一个流(stream),一条消息有多少字节对应用程序是不可见的,因此TCP协议是面向流的协议,这也是容易出现粘包问题的原因。而UDP是面向消息的协议,每个UDP段都是一条消息,应用程序必须以消息为单位提取数据,不能一次提取任意字节的数据,这一点和TCP是很不同的。怎样定义消息呢?可以认为对方一次性write/send的数据为一个消息,需要明白的是当对方send一条信息的时候,无论底层怎样分段分片,TCP协议层会把构成整条消息的数据段排序完成后才呈现在内核缓冲区。

    例如基于tcp的套接字客户端往服务端上传文件,发送时文件内容是按照一段一段的字节流发送的,在接收方看了,根本不知道该文件的字节流从何处开始,在何处结束

    所谓粘包问题主要还是因为接收方不知道消息之间的界限,不知道一次性提取多少字节的数据所造成的。

    此外,发送方引起的粘包是由TCP协议本身造成的,TCP为提高传输效率,发送方往往要收集到足够多的数据后才发送一个TCP段。若连续几次需要send的数据都很少,通常TCP会根据优化算法把这些数据合成一个TCP段后一次发送出去,这样接收方就收到了粘包数据。

    1. TCP(transport control protocol,传输控制协议)是面向连接的,面向流的,提供高可靠性服务。收发两端(客户端和服务器端)都要有一一成对的socket,因此,发送端为了将多个发往接收端的包,更有效的发到对方,使用了优化方法(Nagle算法),将多次间隔较小且数据量小的数据,合并成一个大的数据块,然后进行封包。这样,接收端,就难于分辨出来了,必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。
    2. UDP(user datagram protocol,用户数据报协议)是无连接的,面向消息的,提供高效率服务。不会使用块的合并优化算法,, 由于UDP支持的是一对多的模式,所以接收端的skbuff(套接字缓冲区)采用了链式结构来记录每一个到达的UDP包,在每个UDP包中就有了消息头(消息来源地址,端口等信息),这样,对于接收端来说,就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。
    3. tcp是基于数据流的,于是收发的消息不能为空,这就需要在客户端和服务端都添加空消息的处理机制,防止程序卡住,而udp是基于数据报的,即便是你输入的是空内容(直接回车),那也不是空消息,udp协议会帮你封装上消息头,实验略

    udp的recvfrom是阻塞的,一个recvfrom(x)必须对唯一一个sendinto(y),收完了x个字节的数据就算完成,若是y>x数据就丢失,这意味着udp根本不会粘包,但是会丢数据,不可靠

    tcp的协议数据不会丢,没有收完包,下次接收,会继续上次继续接收,己端总是在收到ack时才会清除缓冲区内容。数据是可靠的,但是会粘包。

    两种情况下会发生粘包。

    发送端需要等缓冲区满才发送出去,造成粘包(发送数据时间间隔很短,数据了很小,会合到一起,产生粘包)

    接收方不及时接收缓冲区的包,造成多个包接收(客户端发送了一段数据,服务端只收了一小部分,服务端下次再收的时候还是从缓冲区拿上次遗留的数据,产生粘包) 

    拆包的发生情况

    当发送端缓冲区的长度大于网卡的MTU时,tcp会将这次发送的数据拆成几个数据包发送出去。

    补充问题一:为何tcp是可靠传输,udp是不可靠传输

    基于tcp的数据传输请参考我的另一篇文章http://www.cnblogs.com/linhaifeng/articles/5937962.html,tcp在数据传输时,发送端先把数据发送到自己的缓存中,然后协议控制将缓存中的数据发往对端,对端返回一个ack=1,发送端则清理缓存中的数据,对端返回ack=0,则重新发送数据,所以tcp是可靠的

    而udp发送数据,对端是不会返回确认信息的,因此不可靠

    补充问题二:send(字节流)和recv(1024)及sendall

    recv里指定的1024意思是从缓存里一次拿出1024个字节的数据

    send的字节流是先放入己端缓存,然后由协议控制将缓存内容发往对端,如果待发送的字节流大小大于缓存剩余空间,那么数据丢失,用sendall就会循环调用send,数据不会丢失

    socket的connect和ACCEPT的实现细节。
    什么是socket ?
    socket是在应用层和传输层之间的一个抽象层,它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用,也就是说你不用再管tcp协议细节及send、recv实现细节。简单的说,Socket就是利用服务器和客户端解决进程间通信连接的问题。
    对于socket connect的理解:
    友好的socket层对程序员屏蔽了很多协议的细节,比如三次握手,那么TCP三次握手是哪个阶段开始的? 下面的流程图说的很清楚是客户端端在调用connect()时建立的三次握手。 另外我们还需要注意两个队列,一个syn队列,一个accept队列。
     
    socket ACCEPT的实现:
    用户连接server之后会选择跟server的哪个socket进行传送数据,新客户端又跟哪个socket建立连接?
    首先要明确,ACCEPT()是从ACCEPT队列里面取出客户端的SYN请求,然后完成三次握手,并且socket server对于每个client都会创建一个新的socketfd,然后通过socketfd来和client完成数据传输。
    对于TCP/IP协议栈是维护者一个接受和发送缓冲区的。在接受到来自客户端的数据包后,服务器端的TCP/IP协议栈会做如下处理:
    如果收到的是请求链接的数据包,则传给监听者连接请求端口的socketfd套接字,
    如果是已经建立过链接的客户端的数据包,则将数据放入接受缓冲区。这样,当服务器端需要读取指定客户端的数据时,则可以利用socketfd_new套接字通过recv或者read函数到缓冲区里去取指定的数据(因为socketfd_new代表的socket对象记录了客户端IP和端口,以此鉴别)。
    数据包如何找到相对应的socket,这个方法在Linux kernel代码里也是有体现的。
    static inline struct sock *__inet_lookup(struct net *net,
    struct inet_hashinfo *hashinfo,
    const __be32 saddr, const __be16 sport,
    const __be32 daddr, const __be16 dport,
    const int dif)
    {
    u16 hnum = ntohs(dport);
    /* 先尝试查找处于连接成功的socket */
    struct sock *sk = __inet_lookup_established(net, hashinfo,
    saddr, sport, daddr, hnum, dif);
    /* 如果没有找到连接成功的socket,那么就去处于listen状态的socket查找 */
    return sk ? : __inet_lookup_listener(net, hashinfo, daddr, hnum, dif);
    }
     
    总结整个过程:
    服务器端在调用listen之后,内核会建立两个队列,SYN队列和ACCEPT队列,其中ACCEPT队列的长度是由backlog指定的。
    服务器端在调用ACCEPT之后,将阻塞,等待ACCEPT队列的元素,
    客户端在调用connect之后,将开始发起SYN请求,请求与服务器建立连接,此时成为第一次握手。
    服务器端在接受到SYN请求之后,把请求方放入SYN队列中,并给客户端回复一个确认帧ACK,此帧还会携带一个请求与客户端简历连接的请求标志,也就是SYN,这成为第二次握手。
    客户端收到SYN+ACK帧后,connect返回,并发送确认建立连接帧ACK给服务器端。这称为第三次握手。
    服务器端收到ACK帧后,把请求方从SYN队列中移出,防止ACCEPT队列,而ACCEPT()函数也等到了自己的资源,从阻塞中唤醒,从ACCEPT队列中取出请求方,重新简历一个新的sockfd,并返回。
    这就是listen,ACCEPT,connect这三个函数的工作流程和原理。从这个过程中可以看到,在connect函数中发生了两次握手。
  • 相关阅读:
    PAT 1036 Boys vs Girls (25分) 比大小而已
    idea创建maven项目慢的原因以及解决方案
    git diff 理解
    git status 命令详解
    java注解
    单例模式
    io分类
    数据库设计的范式
    mysql约束
    mysql去重复关键字distinct的用法
  • 原文地址:https://www.cnblogs.com/jinyudong/p/7818709.html
Copyright © 2011-2022 走看看