python的基础网络编程是下列哪一项_Python基础（十三）-网络编程

一、OSI七层模型

互联网协议按照功能不同分为osi七层或tcp/ip五层或tcp/ip四层

二、socket介绍

2.1、socket位置

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。我们无需深入理解tcp/udp协议，socket已经为我们封装好了，我们只需要遵循socket的规定去编程，写出的程序自然就是遵循tcp/udp标准的

2.2、socket分类

套接字有两种(或者称为有两个种族),分别是基于文件型的和基于网络型：

1)基于文件类型的套接字家族

套接字家族的名字：AF_UNIX

2)基于网络类型的套接字家族

套接字家族的名字：AF_INET

2.3、socket工作流程

文字说明：服务器端先初始化Socket，然后与端口绑定(bind)，对端口进行监听(listen)，调用accept阻塞，等待客户端连接。在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束

socket()模块函数使用：

三、基于TCP的套接字

tcp三次握手与四次挥手：

tcp是基于连接的，必须先起启动服务端，然后在启动客户端取连接服务端

tcp服务端：

tcp客户端：

注意：当重启服务器(linux等)，会出现如下状况，同时服务器会出现time_wait2状态

解决方法：

方法一：==>立刻就可以启动

方法二：==>centos7测试不行

四、基于UDP的套接字

udp是无连接的，先启动哪一端都不会报错

服务端：

客户端：

五、模拟QQ聊天

服务端：

客户端1:

客户端2：

六、时间服务器

服务端：

客户端：

七、基于tcp实现远程命令

服务端：

客户端：

注意：当使用基于TCP制作远程执行命令程序时，当执行dir，ipconfig等命令时会出现粘包

八、基于udp实现远程命令

基于udp的socket在运行时不会发生粘包

服务端和客户端可以在linux服务器上运行，在windows上报：OSError: [WinError 10040] 一个在数据报套接字上发送的消息大于内部消息缓冲区或其他一些网络限制，或该用户用于接收数据报的缓冲区比数据报小。

服务端：

客户端：

九、粘包

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

9.1 、socket收发消息原理

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

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

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

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

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

9.2、粘包产生的情形

情形一：

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

情形二：

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

====================================================================

1)拆包的发生情况

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

2)为何tcp是可靠传输，udp是不可靠传输

tcp在数据传输时，发送端先把数据发送到自己的缓存中，然后协议控制将缓存中的数据发往对端，对端返回一个ack=1，发送端则清理缓存中的数据，对端返回ack=0，则重新发送数据，所以tcp是可靠的

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

3)send(字节流)和recv(1024)及sendall

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

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

====================================================================

9.3、粘包解决思路

问题的根源在于，接收端不知道发送端将要传送的字节流的长度，所以解决粘包的方法就是围绕，如何让发送端在发送数据前，把自己将要发送的字节流总大小让接收端知晓，然后接收端来一个死循环接收完所有数据

9.3.1、方法一

服务端：

客户端：

缺点: 程序的运行速度远快于网络传输速度，所以在发送一段字节前，先用send去发送该字节流长度，这种方式会放大网络延迟带来的性能损耗

9.3.2、方法二：使用struct模块

为字节流加上自定义固定长度报头，报头中包含字节流长度，然后一次send到对端，对端在接收时，先从缓存中取出定长的报头，然后再取真实数据

struct模块：该模块可以把一个类型，如数字，转成固定长度的bytes

服务端：

客户端：

十、socketserver实现并发

可以查看socketserver源码，查看继承关系

服务端：

客户端：