专栏首页python3Python—网络编程Socket

Python—网络编程Socket

网络编程Socket

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

所以开发人员无需深入理解tcp/udp协议,socket已经为我们封装好了,我们只需要遵循socket的规定去编程,写出的程序自然就是遵循tcp/udp标准的。

1.UDP套接字

  udp服务端:

1 ss = socket() #创建一个服务器的套接字 2 ss.bind() #绑定服务器套接字 3 inf_loop: #服务器无限循环 4cs = ss.recvfrom()/ss.sendto() # 对话(接收与发送) 5 ss.close() # 关闭服务器套接字   udp客户端:

1 cs = socket() # 创建客户套接字 2 comm_loop: # 通讯循环 3 cs.sendto()/cs.recvfrom() # 对话(发送/接收) 4 cs.close() # 关闭客户套接字 2.recv与recvfrom的区别:

part1:

发消息都是将数据发送到己端发送缓冲中,收消息都是从己端的缓冲区中收

tcp:send发消息,recv收消息

udp:sendto发消息,recvfrom收消息

part2:

tcp是基于数据流的,而udp是基于数据报的

send(bytes_data):发送数据流,数据流bytes_data若为空,自己这段的缓冲区也为空,操作系统不会控制tcp协议发空包

sendinto(bytes_data,ip_port):发送数据报,bytes_data为空,还有ip_port,所有即便是发送空的butes_data,数据报其实也不是空的,自己这端的缓冲区收到内容,操作系统就会控制udp协议发包.

part3:

1.tcp协议:

(1)如果收消息缓冲区里的数据为空,那么recv就会阻塞(阻塞很简单,就是一直在等着接收)

(2)只不过tcp协议的客户端send一个空数据就是真的空数据,客户端即使有无穷个send空,也跟没有一个样.

(3)tcp基于链接通信

 *基于链接,则需要listen(backlog),指定半连接池的大小

 *基于链接,必须先运行的服务端,然后客户端发起链接请求

 *对于Mac空系统:如果一段断开了链接,那另外一端的链接也跟着完蛋recv将不会阻塞,收到的是空(解决方法是:服务端在收消息后加上if判断,空消息就break掉通信循环)

 *对于Windows/Linux系统:如果一端断开了链接,那另外一端的链接也跟着完蛋recv将不会阻塞,收到的是空(解决方法:服务端通信循环内加异常处理,捕捉到异常后就break掉通讯循环)

2.udp协议

(1)如果收消息缓冲区里的数据为"空",recvfrom也会阻塞

(2)支部会udp协议的客户端sendinto一个空数据并不是真的空数据(包含:空数据+地址信息,得到的报仍然不会为空),所以客户端只要有一个sendinto(不管是否发送空数据,都不会真的空数据),服务端就可以recvfrom到数据.

(3)udp无链接

*无链接,因而无需listen(backlog),更加没有什么连接池之说了

*无链接,udp的sendinto不用管是否有一个正在运行的服务端,可以己端一个劲的发消息,只不过数据丢失

*recvfrom收的数据小于sendinto发送的数据时,在Mac和Linux系统上数据直接丢失,在Windows系统上发送的比接受的大直接报错

*只有sendinto发送数据没有recvfrom收数据,数据丢失

  PS:

    1.你单独运行上面的udp的客户端,你发现并不会报错,相反tcp却会报错,因为udp协议只负责把包发出去,对方收不收,我根本管不着,而tcp是基于链接的,必须有一个服务端先运行着,客户端去跟服务端建立连接然后依托于连接才能传递消息,任何一方试图把连接摧毁都会导致对方程序崩溃

    2.上面的udp程序,你注释任何一条客户端的sendinto,服务端都会卡住,为什么?因为服务端有几个recvfrom就要对应几个sendinto,哪怕是sendinto(b'')那也要有.

3.粘包现象:

  只有TCP有粘包现象,UDP永远不会粘包!

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

  以下情况会发生粘包:

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

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • python随机取list中的元素

    py3study
  • python---文件操作

    py3study
  • 3Python全栈之路系列之基于sock

    发布时间:2017年3月16日 00:04 浏览(106) 评论(0) 分类:Python

    py3study
  • 一个有关tcp的非常有意思的问题

    在tcp建立连接后,先主动关闭其服务端,之后再在客户端下对其socket进行写操作,正常思维都会认为,这个写操作肯定会返回错误吧?

    wangyuntao
  • 一文读懂分库分表的技术演进(最佳实践)

    以支付宝用户为例,8亿;微信用户更是10亿。订单表更夸张,比如美团外卖,每天都是几千万的订单。淘宝的历史订单总量应该百亿,甚至千亿级别,这些海量数据远不是一张表...

    芋道源码
  • PAT 1014 Waiting in Line (模拟)

    1014. Waiting in Line (30) 时间限制 400 ms 内存限制 65536 kB 代码长度限制 16000 B ...

    ShenduCC
  • 越早知道越好的五个Python特性

    即使您是一个从其他语言(如C或MATLAB)转换过来的程序员,用更高抽象级别的Python编写代码绝对是另一种体验。我希望早些时候就知道一些Python特性,并...

    AiTechYun
  • pandas(ix & iloc &loc)区别

    loc——通过行标签索引行数据 iloc——通过行号索引行数据 ix——通过行标签或者行号索引行数据(基于loc和iloc 的混合)

    周小董
  • cssjshtml vue.js lazy在失去焦点时改变

    葫芦
  • Code Forces 650 C Table Compression(并查集)

    C. Table Compression time limit per test4 seconds memory limit per test256 m...

    ShenduCC

扫码关注云+社区

领取腾讯云代金券