标签：ftps 模仿 设计 读取 文件的 发展史 发送消息 cal 属性
客户端（Client）服务器（Server）架构，即C/S架构，包括
1.硬件C/S架构(打印机)
2.软件C/S架构(web服务)
理想/目标状态——
最常用的软件服务器是 Web 服务器。一台机器里放一些网页或 Web 应用程序,然后启动 服务。这样的服务器的任务就是接受客户的请求,把网页发给客户(如用户计算机上的浏览器),然 后等待下一个客户请求。这些服务启动后的目标就是“永远运行下去”。虽然它们不可能实现这样的 目标,但只要没有关机或硬件出错等外力干扰,它们就能运行非常长的一段时间。
生活中的C/S架构：
饭店是S端（服务端），所有的客人是C端（客户端）
互联网中处处是C/S架构（商城网站是服务端，你的浏览器是客户端；腾讯作为服务端为你提供视频，你得下个腾讯视频客户端才能看视频）
C/S架构与socket的关系：
我们学习socket就是为了完成C/S架构的开发
计算机系统和网络协议——
一个完整的计算机系统是由硬件、操作系统、应用软件三者组成,具备了这三个条件，一台计算机系统就可以自己跟自己玩了（打个单机游戏，玩个扫雷啥的）
如果你要跟别人一起玩，那你就需要上网了，互联网的核心就是由一堆协议组成，协议就是标准，全世界人通信的标准是英语，如果把计算机比作人，互联网协议就是计算机界的英语。所有的计算机都学会了互联网协议，那所有的计算机都就可以按照统一的标准去收发信息从而完成通信了。人们按照分工不同把互联网协议从逻辑上划分了层级。
详见网络通信原理：http://www.cnblogs.com/bigtreei/p/7929793.html
为何学习socket一定要先学习互联网协议：
1.首先：本篇目标就是教会你如何基于socket编程，来开发一款自己的C/S架构软件
2.其次：C/S架构的软件（软件属于应用层）是基于网络进行通信的
3.然后：网络的核心即一堆协议，协议即标准；你想开发一款基于网络通信的软件，就必须遵循这些标准。
4.最后：就让我们从这些标准开始研究，开启我们的socket编程之旅。
TCP/IP协议族包括运输层、网络层、链路层。
在上图，我们没有看到Socket的影子，那么它到底在哪里呢？还是用图来说话，一目了然。
socket把那一堆协议封装起来，调用socket也就可以实现那些协议能实现的功能
socket通常也称作"套接字"，用于描述IP地址和端口，应用程序通常通过"套接字"向网络发出请求或者应答网络请求。
Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。
所以，我们无需深入理解tcp/udp协议，socket已经为我们封装好了，我们只需要遵循socket的规定去编程，写出的程序自然就是遵循tcp/udp标准的。
也有人将socket说成ip+port，ip是用来标识互联网中的一台主机的位置，而port是用来标识这台机器上的一个应用程序，
ip地址是配置到网卡上的，而port是应用程序开启的，ip与port的绑定就标识了互联网中独一无二的一个应用程序。
而程序的PID是同一台机器上不同进程或者线程的标识
套接字起源于 20 世纪 70 年代加利福尼亚大学伯克利分校版本的 Unix,即人们所说的 BSD Unix。 因此,有时人们也把套接字称为“伯克利套接字”或“BSD 套接字”。
一开始,套接字被设计用在同 一台主机上多个应用程序之间的通讯。这也被称进程间通讯,或 IPC。套接字有两种（或者称为有两个种族）,分别是基于文件型的和基于网络型的。
基于文件类型的套接字家族——
套接字家族的名字：AF_UNIX
unix一切皆文件，基于文件的套接字调用的就是底层的文件系统来取数据，两个套接字进程运行在同一机器，可以通过访问同一个文件系统间接完成通信。
基于网络类型的套接字家族——
套接字家族的名字：AF_INET
还有AF_INET6被用于ipv6，还有一些其他的地址家族，不过，他们要么是只用于某个平台，要么就是已经被废弃，或者是很少被使用，或者是根本没有实现；
所有地址家族中，AF_INET是使用最广泛的一个，python支持很多种地址家族，但是由于我们只关心网络编程，所以大部分时候我么只使用AF_INET。
一个生活中的场景：
你要打电话给一个朋友，先拨号，朋友听到电话铃声后提起电话，这时你和你的朋友就建立起了连接，就可以讲话了。等交流结束，挂断电话结束此次交谈。生活中的场景就解释了这工作原理。
先从服务器端说起。服务器端先初始化Socket，然后与端口绑定(bind)，对端口进行监听(listen)，调用accept阻塞，等待客户端连接。
在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。
客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束。
import socket
socket.socket(socket_family,socket_type,protocal=0)
socket_family 可以是 AF_UNIX 或 AF_INET。socket_type 可以是 SOCK_STREAM 或 SOCK_DGRAM。protocol 一般不填,默认值为 0。
# 获取tcp/ip套接字
tcpSock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 获取udp/ip套接字
udpSock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# 由于 socket 模块中有太多的属性。我们在这里破例使用了‘from module import *‘语句。
# 使用 ‘from socket import *‘,我们就把 socket 模块里的所有属性都带到我们的命名空间里了,这样能大幅减短我们的代码。
# 例如
from socket import *
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() 创建一个与该套接字相关的文件
tcp服务端
ss = socket() #创建服务器套接字
ss.bind() #把地址绑定到套接字
ss.listen() #监听链接
inf_loop: #服务器无限循环
cs = ss.accept() #接受客户端链接
comm_loop: #通讯循环
cs.recv()/cs.send() #对话(接收与发送)
cs.close() #关闭客户端套接字
ss.close() #关闭服务器套接字(可选)
tcp客户端
cs = socket() # 创建客户套接字
cs.connect() # 尝试连接服务器
comm_loop: # 通讯循环
cs.send()/cs.recv() # 对话(发送/接收)
cs.close() # 关闭客户套接字
socket通信流程与打电话流程类似，我们就以打电话为例来实现一个low版的套接字通信
服务端：
#TCP服务端
import socket
phone=socket.socket(socket.AF_INET,socket.SOCK_STREAM) #AF_INET基于网络类型的套接字家族;SOCK_STREAM,TCP协议。“买手机”
phone.bind(("127.0.0.1",8080)) #绑定ip地址,绑定(主机,端口号)到套接字,127.0.0.1,8080参数ip地址和端口号。“绑定手机”
phone.listen(5) #开始TCP监听，同时挂起5个客户端账户，一般定义参数，写入配置文件中，可进行修改。“开机”
print("start...")
conn,addr=phone.accept() #接收客户端的链接和IP地址；被动接受TCP客户端的连接,(阻塞式)等待连接的到来。“等待电话的链接”
print("客户端的信息是(电话线路是)",conn)
print("客户端的ip地址和端口是（客户端手机号是）",addr)
data=conn.recv(1024) #接收的客户端TCP数据。此时1024为最大设置，收消息来自缓存，内存有限，参数太大也没什么卵用。
print("客户端发来的消息是",data)
conn.send(data.upper()) # 发送给客户端TCP数据(send在待发送数据量大于己端缓存区剩余空间时,数据丢失,不会发完)
conn.close() #关闭客户端套接字,"挂电话"
phone.close() #关闭服务端套接字,"关机"
运行服务端
# 运行服务端输出结果：
start... #程序停滞，没有接收到客户端消息
客户端：
#TCP客户端
import socket
phone=socket.socket(socket.AF_INET,socket.SOCK_STREAM) #AF_INET基于网络类型的套接字家族;SOCK_STREAM,TCP协议。“买手机”
phone.connect(("127.0.0.1",8080)) #链接服务器，127.0.0.1,8080为服务端的ip地址和端口
phone.send("hello".encode("utf8")) #客户端发送消息需要是bytes格式。因为发送消息是在应用层上，应用层发送给本机网络层-->链路层-->物理层，物理层是通过电信号二进制来交换信息
data=phone.recv(1024) #接收到的服务端消息
print(data)
phone.close() #关闭客户端套接字
运行客户端
# 执行客户端输出的结果：
b‘HELLO‘ #输出b‘HELLO‘,客户端程序结束。
再次看服务端运行结果，服务端程序执行完毕。
start...
客户端的信息是(电话线路是) <socket.socket fd=244, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=(‘127.0.0.1‘, 8080), raddr=(‘127.0.0.1‘, 52088)>
客户端的ip地址和端口是（客户端手机号是） (‘127.0.0.1‘, 52088)
客户端发来的消息是 b‘hello‘
因为服务端和客户端都在本机，所以ip地址相同，但是端口号不同。
上述流程的问题是，服务端只能接受一次链接，然后就彻底关闭掉了，实际情况应该是，服务端不断接受链接，然后循环通信，通信完毕后只关闭链接，服务器能够继续接收下一次链接，下面是修改版。
服务端客户端但是上述又有问题了
1.当客户端发送中文时，显示的不是中文而是二进制。
解决方法：在客户端和服务端打印输出消息时将消息用utf8解码。
2.当客户端发送的内容为空时，客户端卡掉。因为客户端发送给服务端消息等待服务端反馈，发送更改为大写字母打印内容。但客户端发送的为空，服务端一直接收不了，也无法反馈给客户端，客户端也一直在等待，所以客户端卡掉了。
解决方法：客户端加一条判断语句if not msg:continue。
3.当客户端中止操作程序时，window下服务端报错，linux下服务器一直收空。
解决方法：服务端加上try...except Exception:break来避免报错。但是错误避免了，服务端也跟着结束程序了。
服务端启动后不能中止程序，所以加上while True: 语句来实现不同的客户端账号再次访问时能正常工作，因为可能访问的客户端ip地址不同，所以while True: 语句应该放置在 接收客户端的链接和IP地址conn,addr=phone.accept()的语句上方。
最终程序优化如下：
服务端客户端
当重启服务端程序时会出现错误：OSError: [WinError 10048] 通常每个套接字地址(协议/网络地址/端口)只允许使用一次。
这个是由于你的服务端仍然存在四次挥手的time_wait状态在占用地址
（如果不懂，请深入研究1.tcp三次握手，四次挥手 2.syn洪水攻击 3.服务器高并发情况下会有大量的time_wait状态的优化方法）
解决方法一：在服务端phone.bind(("127.0.0.1",8080))语句前加phone.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)
解决方法二：
解决方法二
#服务端
import socket
phone=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
ip_port=("127.0.0.1",8080)
phone.bind(ip_port)
phone.listen(5)
con,addr=phone.accept()
data1=con.recv(1024)
data2=con.recv(1024)
print("第一次接收到客户端发送的信息是",data1)
print("第二次接收到客户端发送的信息是",data2)
con.close()
phone.close()
#客户端
import socket
phone=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
phone.connect(("127.0.0.1",8080))
phone.send("hello world".encode("utf8"))
phone.send("haha".encode("utf8"))
phone.close()
运行服务端结果：
第一次接收到客户端发送的信息是 b‘hello worldhaha‘
第二次接收到客户端发送的信息是 b‘‘
客户端第一次发送的hello world和第二次发送的haha粘在一起了。
粘包原因:
发送端可以是一K一K地发送数据，而接收端的应用程序可以两K两K地提走数据，当然也有可能一次提走3K或6K数据，或者一次只提走几个字节的数据，也就是说，应用程序所看到的数据是一个整体，或说是一个流（stream），一条消息有多少字节对应用程序是不可见的，因此TCP协议是面向流的协议，这也是容易出现粘包问题的原因。
基于tcp的套接字客户端往服务端上传文件，发送时文件内容是按照一段一段的字节流发送的，在接收方看了，根本不知道该文件的字节流从何处开始，在何处结束。
所谓粘包问题主要还是因为接收方不知道消息之间的界限，不知道一次性提取多少字节的数据所造成的。
此外，发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一个TCP段。若连续几次需要send的数据都很少，通常TCP会根据优化算法把这些数据合成一个TCP段后一次发送出去，这样接收方就收到了粘包数据。
TCP（transport control protocol，传输控制协议）是面向连接的，面向流的，提供高可靠性服务。收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。
tcp的协议数据不会丢，没有收完包，下次接收，会继续上次继续接收，己端总是在收到ack时才会清除缓冲区内容。数据是可靠的，但是会粘包。
两种情况下会发生粘包：
1、发送端需要等缓冲区满才发送出去，造成粘包（发送数据时间间隔很短，数据了很小，会合到一起，产生粘包）
#服务端
from socket import *
ip_port=(‘127.0.0.1‘,8080)
tcp_socket_server=socket(AF_INET,SOCK_STREAM)
tcp_socket_server.bind(ip_port)
tcp_socket_server.listen(5)
conn,addr=tcp_socket_server.accept()
data1=conn.recv(10)
data2=conn.recv(10)
print(‘----->‘,data1.decode(‘utf-8‘))
print(‘----->‘,data2.decode(‘utf-8‘))
conn.close()
#客户端
import socket
BUFSIZE=1024
ip_port=(‘127.0.0.1‘,8080)
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
res=s.connect_ex(ip_port)
s.send(‘hello‘.encode(‘utf-8‘))
s.send(‘xuyaping‘.encode(‘utf-8‘))
运行程序结果：
-----> helloxuyap
-----> ing
2、接收方不及时接收缓冲区的包，造成多个包接收（客户端发送了一段数据，服务端只收了一小部分，服务端下次再收的时候还是从缓冲区拿上次遗留的数据，产生粘包）
#服务端
from socket import *
ip_port=(‘127.0.0.1‘,8080)
tcp_socket_server=socket(AF_INET,SOCK_STREAM)
tcp_socket_server.bind(ip_port)
tcp_socket_server.listen(5)
conn,addr=tcp_socket_server.accept()
data1=conn.recv(2) #一次没有收完整
data2=conn.recv(20)#下次收的时候,会先取旧的数据,然后取新的
print(‘----->‘,data1.decode(‘utf-8‘))
print(‘----->‘,data2.decode(‘utf-8‘))
conn.close()
#客户端
import socket
BUFSIZE=1024
ip_port=(‘127.0.0.1‘,8080)
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
res=s.connect_ex(ip_port)
s.send(‘hello xuyaping‘.encode(‘utf-8‘))
s.send(‘haha‘.encode(‘utf-8‘))
服务端运行结果：
-----> he
-----> llo xuyapinghaha
拆包的发生情况
当发送端缓冲区的长度大于网卡的MTU时，tcp会将这次发送的数据拆成几个数据包发送出去。
简陋方法：加time.sleep() 睡眠一段时间比网络延迟时间长，先传送第一次发送给服务端的信息。
#服务端
import socket
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ip_port = ("127.0.0.1", 8080)
phone.bind(ip_port)
phone.listen(5)
con, addr = phone.accept()
data1 = con.recv(1024)
data2 = con.recv(1024)
print("第一次接收到客户端发送的信息是", data1)
print("第二次接收到客户端发送的信息是", data2)
con.close()
phone.close()
#客户端
import socket
import time
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
phone.connect(("127.0.0.1", 8080))
phone.send("hello world".encode("utf8"))
time.sleep(3)
phone.send("haha".encode("utf8"))
phone.close()
服务端运行结果：
第一次接收到客户端发送的信息是 b‘hello world‘
第二次接收到客户端发送的信息是 b‘haha‘
睡3s，比网络延迟长，hello world先被送走，haha再次被送走。解决了粘包问题。
但是程序运行速度太慢...
优化版:根据每次收到的消息字节长度来进行处理。
#服务端
import socket
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ip_port = ("127.0.0.1", 8080)
phone.bind(ip_port)
phone.listen(5)
con, addr = phone.accept()
data1 = con.recv(10) #客户端第一次发送10个字节的消息
data2 = con.recv(1024)
print("第一次接收到客户端发送的信息是", data1)
print("第二次接收到客户端发送的信息是", data2)
con.close()
phone.close()
#客户端
import socket
import time
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
phone.connect(("127.0.0.1", 8080))
phone.send("helloworld".encode("utf8"))
phone.send("haha".encode("utf8"))
phone.close()
运行服务器结果：
第一次接收到客户端发送的信息是 b‘helloworld‘
第二次接收到客户端发送的信息是 b‘haha‘
你自己发送的到达对方后你的软件不知道数据内容。
开发程序需要你自己定义协议，但是以上都没有自己定义协议，只是把数据发送出去而已。所以需要模仿协议格式来为你的应用数据封装一个应用数据的头。
报头：1.固定长度，自己知道自己的数据长度，规避粘包问题。
2.包含对将要发送数据的描述信息。
基于tcp的套接字实现远程执行命令的操作
上述详细代码：http://www.cnblogs.com/bigtreei/p/7929750.html
在以上程序的基础上解决粘包问题。
实现远程执行命令远程执行命令——客户端但上述解决粘包问题同样不完善，多了中间的网络延迟，卡着收确认信息。
程序的运行速度远快于网络传输速度，所以在发送一段字节前，先用send去发送该字节流长度，这种方式会放大网络延迟带来的性能损耗。
最终优化版：自定义报头解决粘包问题
为字节流加上自定义固定长度报头，报头中包含字节流长度，然后一次send到对端，对端在接收时，先从缓存中取出定长的报头，然后再取真实数据。
上述涉及到struct模块的使用。
struct：
该模块可以把一个类型，如数字，转成固定长度的bytes
struct.pack(‘i‘,1111111111111)
struct.error: ‘i‘ format requires -2147483648 <= number <= 2147483647 #这个是第二个参数的范围。
详细用法可参考：http://www.cnblogs.com/coser/archive/2011/12/17/2291160.html
使用struct模块解决粘包的问题，定制自己的报头：
使用struct模块，对数据大小长度是有限制的，超过这个数据范围，报错。单纯的把数据长度打成bytes格式很可能会超出范围，而且报头不只有数据长度一个内容，还有各种信息等等...
此时需要将数据信息写成字典的形式来避免数据大小超出范围，并且需要json作为中介来实现struct模块的使用。
head_dir={‘data_size‘:111111111111111111111111111,‘hash‘:None,‘filename‘:‘a.txt‘}
1.使用json模块转成json格式的字符串
import json
head_json=json.dumps(head_dic)
print(head_json)
--->{‘data_size‘:111111111111111111111111111,‘hash‘:None,‘filename‘:‘a.txt‘} #json格式的字符串
2.json字符串格式转成bytes格式
head_bytes=head_json.encode(‘utf8‘)
print(head_bytes)
--->b{‘data_size‘:111111111111111111111111111,‘hash‘:None,‘filename‘:‘a.txt‘}
此时bytes格式就是报头，struct.pack将报头bytes格式的数据大小打包成固定大小为4个字节：
head_len=struct.pack(‘i‘,len(head_bytes))
终极大招——最终优化程序：
终极大招——服务端终极大招——客户端
使用模块socket同一时间下只能实现一个客户端与服务端的交互，没法实现二个客户端与服务端的交互。
基于本篇 七、基于TCP的套接字 的内容，最终优化版程序运行服务端，运行客户端1，再运行一次相同代码的客户端2发现客户端2
不能运行，输入msg后就卡住不能运行。是因为服务端的通信循环一直和客户端1建立链接，客户端2不能和服务端进行通信循环。
socketserver模块两大类解决两个问题：
server类：解决一直运行提供服务（连接循环）
request类：解决基于一个链接的通信循环
使用socketserver模块
#服务端，此时服务端程序不完整，只是为了查看部分参数到底是什么
import socketserver
class FTPserver(socketserver.BaseRequestHandler): #继承的类socketserver.BaseRequestHandler是固定的
def handle(self): #定义的方法handle也是固定的
print("self：",self)
print("self.request：",self.request) #self.request即一个链接,相当于conn
print("self.server：",self.server) #self.server即套接字对象
print("self.client_address:",self.client_address) #即客户端地址
if __name__=="__main__":
obj=socketserver.ThreadingTCPServer(("127.0.0.1",8080),FTPserver)
#ThreadingTCPServer线程，自动触发类FTPserver下的handle函数的运行。类的实例化:详细的过程请查看源码，各种继承。
obj.serve_forever() #链接循环，对象的调用
#下面为运行服务端然后再运行客户端后输出的结果：
--->self： <__main__.FTPserver object at 0x0000000001E3A8D0>
self.request： <socket.socket fd=204, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=(‘127.0.0.1‘, 8080), raddr=(‘127.0.0.1‘, 53195)>
self.server： <socketserver.ThreadingTCPServer object at 0x0000000001E2D5C0>
self.client_address: (‘127.0.0.1‘, 53195)
#客户端
import socket
phone=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
phone.connect(("127.0.0.1",8080))
while True:
msg=input(">>:").strip()
if not msg:continue
phone.send(msg.encode("utf8"))
data=phone.recv(1024)
print(data)
phone.close()
使用socketserver模块实现并发
#服务端：
import socketserver
class MyFTP(socketserver.BaseRequestHandler):
def handle(self):
while True:
data = self.request.recv(1024)
self.request.send(data.upper())
if __name__ == ‘__main__‘:
obj = socketserver.ThreadingTCPServer((‘127.0.0.1‘,8484),MyFTP) #完成了bind绑定ip+port和listen监听的操作。
obj.serve_forever() #永远接收链接。完成了accept的操作
#每个客户端：
import socket
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
phone.connect((‘127.0.0.1‘,8484)) #服务器ip地址和端口号
while True: #通信循环
msg = input(‘>>:‘).strip()
if msg == ‘‘:continue
phone.send(msg.encode(‘utf-8‘)) #发送消息
data = phone.recv(1024) #接收消息，从缓存中每次最大取字节为1024个字节
print(data)
phone.close() #结束通信
用户数据报协议，无连接，面向消息的，自带报头（发空没事，不会粘包）。
tcp和udp差别：
1.tcp是可靠传输，udp是不可靠传输。udp是无链接的，发消息根本不管对方收不收到，发完就结束。当udp客户端先启动再启动服
务端也不会报错，但是信息就会丢失。
2.tcp可靠是因为有链接，发包有回应。udp没链接，所以不需要listen，那么也不要接收链接accept。
3.udp可以收空并且不报错。因为udp表面上收的是空，但是是报头，实质上不为空。
基于udp套接字的示例
#服务端：
import socket
host_ip = ‘127.0.0.1‘
host_port = 8080
udp_server = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
udp_server.bind((host_ip,host_port))
while True:
conn, addr = udp_server.recvfrom(1024)
print(conn, addr)
udp_server.sendto(conn.upper(), addr)
#客户端：
import socket
host_ip = ‘127.0.0.1‘
host_port = 8080
udp_client = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
while True:
msg = input(‘>>:‘).strip()
udp_client.sendto(msg.encode(‘utf-8‘),(host_ip,host_port))
conn, addr = udp_client.recvfrom(1024)
print(conn.decode(‘utf-8‘))
标签：ftps 模仿 设计 读取 文件的 发展史 发送消息 cal 属性
原文地址：http://www.cnblogs.com/bigtreei/p/7930395.html
