zoukankan html css js c++ java

网络编程

一、网络架构及其演变过程

1、1 单机架构

应用领域：

    * 植物大战僵尸
    * office

1、2 CS架构

应用领域：

QQ
大型网络游戏

计算机发展初期用户去取数据，直接就去主机拿，从这里开始就分出了客户端和服务端。

客户端：用户安装的软件；

服务端：统一管理数据库的主机中的软件就叫做服务端，再后来服务端不只是管理数据，外加处理业务逻辑。

1、2、1 CS 架构要求

1. 用户操作系统安装客户端；产商操作系统部署客户端

每个用户需要独立安装软件、服务端升级也要每个用户升级

1、2、2 面试题：数据放在服务端和客户端的利与弊？

答：

* 服务端统一处理会有更好的安全性和稳定性而且升级比较容易，不过服务器负担就增加了。
* 客户端将负担分配到每个用户，从而可以节约服务其资源，安全性和稳定性可能会有一定的问题，但是升级不计较麻烦，每个安装的客户端程序都需要升级，另外为了节省网络资源，通过网络传输的数据应该尽量减少！

1、3 BS架构

应用领域：

    * 淘宝
    * 京东

统一客户端即默认安装用户电脑中的浏览器，访问同种类的网站，具体业务的处理根据相应协议和标准提供的服务器，在不同的服务器处理。

1、3、1 两种BS架构

OSI主要用于教学，我们在编程的时候用的都是TCP/IP.

*TCP/IP的对应关系，就像我们在淘宝购物，所在位置有的快递（网络接入层）,告诉卖家地址（网络互联层）、快递发货（运输层）、收到货物拆包使用（应用层）。

注意：

对于广泛使用的东西就需要制定相应的标准，就像大公司有很多制度来规范做事情的流程。由于网络传输应用非常广泛，但是规矩不是强制性的，所以叫做协议而不是标准，TCP/IP参考模型也可以看成是一种协议。BS结构中TCP/IP模型中的网络接入层没有响应的协议，网络互联层是IP协议，传输层是TCP协议，应用层是HTTP协议，另外还是用到了DNS结构，而且在HTTP上层还有响应。

基于BS结构下的程序就要求解决速度问题，而速度问题的核心就是决绝海量数据操作和高并发问题，网站复杂结构就是从这两个问题演变出来的。

1、4 CS架构和BS架构的区别

二、互联网和互联网的组成

2、1 教材版

1. 边缘部分：服务端和客户端

核心部分：路由器/基站（大量的网络和连接这些网络的路由器组成。）

2、2 科普版

硬件：

硬件组成主要包括终端设备，主要是联网的个人设备；组成家庭（企业）局域网、城域网、主干网的网络设备；提供内容服务的服务主机设备等。
1. 终端设备：电脑（pc，笔记本），移动设备（手机，pad），智能电视，智能家居
2. 网络设备：网卡，网线，水晶头，路由器，家用交换机，防火墙设备，中继器，桥接器
3. 主机设备：IDC机房，机柜，精密空调，负载均衡器，服务器，工作站，小型机、大型机
软件：

互联网的软件非常多，不太好分类，大致分成网络协议类，操作系统类，平台中间件类，应用类。
1. 网络协议类，比如互联网的基础协议tcp/ip协议
2. 操作系统类，比如window，linux，macOS，android，iOS
3. 平台中间件类：比如webServer，Nginx，Apache，Tomcat，MySQL等
4. 应用类：比如浏览器，微信，邮箱，游戏等等。

三、大白话OSI七层协议

互联网的本质就是一系列的网络协议，这个协议就叫OSI协议（一系列协议），按照功能不同，分工不同，人为的分层七层。实际上这个七层是不存在的。没有这七层的概念，只是人为的划分而已。区分出来的目的只是让你明白哪一层是干什么用的。

每一层都运行不同的协议。协议是干什么的，协议就是标准。

实际上还有人把它划成五层、四层。

七层划分为：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。

五层划分为：应用层、传输层、网络层、数据链路层、物理层。

四层划分为：应用层、传输层、网络层、网络接口层。

每层运行常见的物理设备

3、1 物理层

物理层字面意思解释：物理传输、硬件、物理特性。在深圳的你与北京的朋友聊天，你的电脑必须要能上网，物理体现是什么？是不是接一根网线，插个路由器，北京的朋友那边是不是也有根网线，也得插个路由器。也就是说计算机与计算机之间的通信，必须要有底层物理层方面的连通，就类似于你打电话，中间是不是必须得连电话线。

中间的物理链接可以是光缆、电缆、双绞线、无线电波。中间传的是电信号，即010101...这些二进制位。

底层传输的010010101001...这些二进制位怎么才能让它有意义呢？

要让这些010010101001...有意思，人为的分组再适合不过了，8位一组，发送及接收都按照8位一组来划分。接收到8位为一组的话，那么就可以按照这8位数来做运算。如果没有分组，对方接收的计算机根本就不知道从哪一位开始来做计算，也解析不了收到的数据。我发了16位你就按照16位来做计算吗？我发100位你就按照100位做计算吗？没什么意义是吧。因此要想让底层的电信号有意义，必须要把底层的电信号做分组。我做好8位一组，那么我收到数据，我就知道这几个8位做一组，这几个8位做一组。那么每个8位就可以得到一个确定的数。分组是谁干的活呢？物理层干不了，这个是数据链路层干的。

3、2 数据链路层

数据链路层的功能：定义了电信号的分组方式

3.2.1 以太网协议

ethernet规定：一组电信号构成一个数据报，叫做'帧'，每一数据帧分成：报头head和数据data两部分

head包含：(固定18个字节)
- 发送者／源地址，6个字节
- 接收者／目标地址，6个字节
- 数据类型，6个字节
data包含：(最短46字节，最长1500字节)

-	-
head	data

数据报的具体内容：head长度＋data长度＝最短64字节，最长1518字节，超过最大限制就分片发送

这就像写信，发送者的地址（源地址）就是你家的地址，接收者地址（目标地址）就是对方的收信地址，你家的路由器就相当于邮局。其实在计算机通信中的源地址和目标地址指的是Mac地址。

3.2.2 Mac地址

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

3.2.3 广播地址

这个数据包封装好以后就往外发，到物理层以后就全部转成二进制，往外发是怎么发的呢？就是靠吼。即“我是nick，我找飞哥要战狼2的片”。这么吼了一嗓子以后，全屋子的人都能听到，这就是广播。

计算机底层，只要在一个教室里（一个局域网），都是靠广播的方式，吼。

广播出去以后，所有人都听得见，所有人都会拆开这个包，读发送者是谁，接收者是谁，只要接收者不是自己就丢弃掉。对计算机来说，它会看自己的Mac地址，飞哥收到以后，他就会把片发给我，发送回来同样采用广播的方式了，靠吼。

同一个教室（同一个局域网）的计算机靠吼来通信，那不同教室的计算机又如何？

比如说局域网1的pc1与局域网2的pc10如何通信？你在教室1（局域网1）吼，教室2（局域网2）的人肯定是听不见的。这就是跨网络进行通信，数据链路层就解决不了这个问题了，这就得靠网络层出面了。

注意：在讲网络层之前，其实基于广播的这种通信就可以实现全世界通信了，你吼一声，如果全世界是一个局域网，全世界的计算机肯定可以听得见，从理论上似乎行得通，如果全世界的计算机都在吼，你想一想，这是不是一个灾难。因此，全世界不能是一个局域网。于是就有了网络层。

3、3 网络层

网络层的由来：有了ethernet、Mac地址、广播的发送方式，世界上的计算机就可以彼此通信了，问题是世界范围的互联网是由一个个彼此隔离的小的局域网组成的，那么如果所有的通信都采用以太网的广播方式，那么一台机器发送的包全世界都会收到

对于上述的问题这就不仅仅是效率低的问题了，这会是一种灾难

为了解决上述灾难，网络层定义了一个IP协议，

你想，我是这个教室的一个学生，我想找隔壁教室一个叫老王的学生，我也不认识老王，那怎么办，我吼？老王在另外一个教室肯定是听不到的。找教室的负责人，这个教室的负责人就负责和隔壁教室的负责人说话，说我们教室的有个学生要找你们教室的老王。往外传的东西交给负责人就可以了，内部的话上面已经提到，通过广播的方式，对外的东西广播失效。教室的负责人就是网关，网关即网络关口的意思。

Mac地址是用来标识你这个教室的某个位置，IP地址是用来标识你在哪个教室（哪个局域网）。你要跨网络发包你是不是要知道对方的IP地址，比如你要访问百度，你肯定得知道百度服务器的IP地址。计算机在发包前，会判断你在哪个教室，对方在哪个教室，如果在一个教室，基于Mac地址的广播发包就OK了；如果不在一个教室，即跨网络发包，那么就会把你的包交给教室负责人（网关）来转发。Mac地址及IP地址唯一标识了你在互联网中的位置。

数据链路层中会把网络层的数据包封装到数数据链路层的数据位置，然后再添加上自己的包头，再发给物理层，物理层发给网关，网关再发给对方教室的网关，对方教室的网关收到后在那个教室做广播。

在数据链路层看，数据封装了两层，跟玩俄罗斯套娃有点类似，一层套了一层。

最终变成

-	-	-
以太网头	IP头	IP数据

现在来看另一个问题，在吼之前怎么知道对方的Mac地址？这就得靠ARP协议。

ARP协议的由来：在你找飞哥要片之前，你的先干一件事，想办法知道飞哥的Mac地址。即你的机器必须先发一个ARP包出去，ARP也是靠广播的方式发，ARP发送广播包的方式如下：

-	源Mac	目标Mac	源IP	目标IP	数据部分
发送端主机	发送端Mac	FF:FF:FF:FF:FF:FF	172.16.10.10/24	172.16.10.11/24	数据

局域网中怎么获取对方的Mac地址：

肯定要知道对方的IP地址，这是最基本的，就像你要访问百度，肯定得知道百度的域名，域名就是百度的IP地址。自己的IP可以轻松获得，自己的Mac也轻松获取，目标Mac为12个F，我们叫广播地址，表达的意思是我想要获取这个目标IP地址172.16.10.11的机器的Mac地址。Mac为12个F代表的是一种功能，这个功能就是获取对方的Mac地址，计算机的Mac永远不可能是12个F。假设是在本教室广播，一嗓子吼出去了，所有人开始解包，只有IP地址是172.16.10.11的这个人才会返回他的Mac地址，其他人全部丢弃。发回来源Mac改成飞哥自己的Mac地址，同时把飞哥的Mac地址放在数据部分。

跨网络怎么获取对方的Mac地址：

通过IP地址区分，计算机运算判断出飞哥不在同一个教室，目标IP就变成了网关的IP了。网关的IP在计算机上配死了，可以轻松获取。

-	源Mac	目标Mac	源IP	目标IP	数据部分
发送端主机	发送端Mac	FF:FF:FF:FF:FF:FF	172.16.10.10/24	172.16.10.11/24	数据

-	源Mac	目标Mac	源IP	目标IP	数据部分
发送端主机	发送端Mac	FF:FF:FF:FF:FF:FF	172.16.10.10/24	网关地址	数据

-	源Mac	目标Mac	源IP	目标IP	数据部分
发送端主机	发送端Mac	网关Mac	172.16.10.10/24	飞哥的IP	数据

注意：网关帮你去找飞哥，但对用户来说，由于速度太快我们根本就感觉不到网关的存在。

3.3.1 IP协议详解

一个IP地址通常写成四段十进制数，例：172.16.10.1

3.3.1 IP地址的两部分

网络部分：标识子网
主机部分：标识主机

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

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

3.3.2 子网掩码详解

知道”子网掩码”后，我们就能判断，任意两个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
- 255.255.255.0:11111111.11111111.11111111.00000000
- AND运算得网络地址结果：10101100.00010000.00001010.000000000->172.16.10.0
172.16.10.2：10101100.00010000.00001010.000000010
- 255.255.255.0:11111111.11111111.11111111.00000000
- AND运算得网络地址结果：10101100.00010000.00001010.000000000->172.16.10.0
结果都是172.16.10.0，因此它们在同一个子网络。

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

3.3.3 IP数据包详解

head：长度为20到60字节
data：最长为65,515字节

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

-	-	-
以太网头	IP头	IP数据

有了Mac地址+IP地址，我们就能确定世界上独一无二的一台计算机。

3.3.4 ARP协议详解

arp协议功能：广播的方式发送数据包，获取目标主机的Mac地址

协议工作方式：每台主机IP都是已知的，例如：主机172.16.10.10/24访问172.16.10.11/24

1.首先通过IP地址和子网掩码区分出自己所处的子网

场景	数据包地址
同一子网	目标主机Mac，目标主机IP
不同子网	网关Mac，目标主机IP

2.分析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	数据

3.这个包会以广播的方式在发送端所处的自网内传输，所有主机接收后拆开包，发现目标IP为自己的，就响应，返回自己的Mac

3、4 传输层

那么我们通过IP和Mac找到了一台特定的主机，如何标识这台主机上的应用程序，答案就是端口，端口即应用程序与网卡关联的编号。

传输层功能：建立端口到端口的通信

补充：端口范围0-65535，0-1023为系统占用端口

有了Mac地址+IP地址+端口，我们就能确定世界上独一无二的一台计算机上的应用程序

3.4.1 TCP协议

-	-	-	-
以太网头	IP头	TCP头	数据

3.4.2 UDP协议

-	-	-	-
以太网头	IP头	UDP头	数据

3.4.3 TCP报文

3.4.4 TCP三次握手和四次挥手

3、5应用层

应用层功能：规定应用程序的数据格式。

例：TCP协议可以为各种各样的程序传递数据，比如Email、WWW、FTP等等。那么，必须有不同协议规定电子邮件、网页、FTP数据的格式，这些应用程序协议就构成了”应用层”。

注意：数据经过以上几层的折腾，已经不成样子了。

四、TCP协议的三次握手和四次挥手

4、1 背景描述

通过OSI七层网络模型中IP层的介绍，我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。

UDP，在传送数据前不需要先建立连接，远地的主机在收到UDP报文后也不需要给出任何确认。虽然UDP不提供可靠交付，但是正是因为这样，省去和很多的开销，使得它的速度比较快，比如一些对实时性要求较高的服务，就常常使用的是UDP。对应的应用层的协议主要有 DNS，TFTP，DHCP，SNMP，NFS 等。

TCP，提供面向连接的服务，在传送数据之前必须先建立连接，数据传送完成后要释放连接。因此TCP是一种可靠的的运输服务，但是正因为这样，不可避免的增加了许多的开销，比如确认，流量控制等。对应的应用层的协议主要有 SMTP，TELNET，HTTP，FTP 等。

4、2常用的熟知端口号

应用程序	FTP	TFTP	TELNET	SMTP	DNS	HTTP	SSH	MYSQL
熟知端口	21,20	69	23	25	53	80	22	3306
传输层协议	TCP	UDP	TCP	TCP	UDP

4、3TCP概述

TCP把连接作为最基本的对象，每一条TCP连接都有两个端点，这种端点我们叫作套接字（socket），它的定义为端口号拼接到IP地址即构成了套接字，例如，若IP地址为192.3.4.16 而端口号为80，那么得到的套接字为192.3.4.16:80。

4、4 TCP报文首部

源端口和目的端口，各占2个字节，分别写入源端口和目的端口；
序号，占4个字节，TCP连接中传送的字节流中的每个字节都按顺序编号。例如，一段报文的序号字段值是 301 ，而携带的数据共有100字段，显然下一个报文段（如果还有的话）的数据序号应该从401开始；
确认号，占4个字节，是期望收到对方下一个报文的第一个数据字节的序号。例如，B收到了A发送过来的报文，其序列号字段是501，而数据长度是200字节，这表明B正确的收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701；
数据偏移，占4位，它指出TCP报文的数据距离TCP报文段的起始处有多远；
保留，占6位，保留今后使用，但目前应都位0；
紧急URG，当URG=1，表明紧急指针字段有效。告诉系统此报文段中有紧急数据；
确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；
推送PSH，当两个应用进程进行交互式通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应，这时候就将PSH=1；
复位RST，当RST=1，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立连接；
同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；
终止FIN，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放；
窗口，占2字节，指的是通知接收方，发送本报文你需要有多大的空间来接受；
检验和，占2字节，校验首部和数据这两部分；
紧急指针，占2字节，指出本报文段中的紧急数据的字节数；
选项，长度可变，定义一些其他的可选的参数。

4、5 TCP连接的建立（三次握手）

最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。

TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；
TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

4、6 TCP四次挥手

数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。

客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗ *∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

4、7 面试题

4.7.1 为什么客户端最后还要等待2MSL ?

保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

4.7.2为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候，服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

4.7.3 如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

五、基于TCP协议的socket套接字编程

5、1 什么是Scoket

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

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

注意：也有人将socket说成ip+port，ip是用来标识互联网中的一台主机的位置，而port是用来标识这台机器上的一个应用程序，ip地址是配置到网卡上的，而port是应用程序开启的，ip与port的绑定就标识了互联网中独一无二的一个应用程序，而程序的pid是同一台机器上不同进程或者线程的标识。

5、2 套接字发展史及分类

套接字起源于 20 世纪 70 年代加利福尼亚大学伯克利分校版本的 Unix,即人们所说的 BSD Unix。因此,有时人们也把套接字称为“伯克利套接字”或“BSD 套接字”。一开始,套接字被设计用在同一台主机上多个应用程序之间的通讯。这也被称进程间通讯,或 IPC。套接字有两种（或者称为有两个种族）,分别是基于文件型的和基于网络型的。

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

套接字家族的名字：AF_UNIX

unix一切皆文件，基于文件的套接字调用的就是底层的文件系统来取数据，两个套接字进程运行在同一机器，可以通过访问同一个文件系统间接完成通信

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

(还有AF_INET6被用于ipv6，还有一些其他的地址家族，不过，他们要么是只用于某个平台，要么就是已经被废弃，或者是很少被使用，或者是根本没有实现，所有地址家族中，AF_INET是使用最广泛的一个，python支持很多种地址家族，但是由于我们只关心网络编程，所以大部分时候我么只使用AF_INET)

5、3 套接字工作流

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

import socket

# socket_family 可以是 AF_UNIX 或 AF_INET。socket_type 可以是 SOCK_STREAM 或 SOCK_DGRAM。protocol 一般不填，默认值为 0
socket.socket(socket_family, socket_type, protocal=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 模块里的所有属性都带到我们的命名空间里了，这样能大幅减短我们的代码
tcpSock = socket(AF_INET, SOCK_STREAM)

5.3.1 服务端套接字函数

方法	用途
s.bind()	绑定(主机,端口号)到套接字
s.listen()	开始TCP监听
s.accept()	被动接受TCP客户的连接,(阻塞式)等待连接的到来

5.3.2 客户端套接字函数

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

5.3.3 公共用途的套接字函数

方法	用途
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()	关闭套接

5.3.4 面向锁的套接字方法

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

5.3.5 面向文件的套接字的函数

方法	用途
s.fileno()	套接字的文件描述符
s.makefile()	创建一个与该套接字相关的文件

5、4 基于TCP协议的套接字编程(简单)

可以通过netstat -an | findstr 8080查看套接字状态

5.4.1 服务端

import socket

#1、买手机
phone = socket.socket(socket.AF_INET,
                      socket.SOCK_STREAM)  #tcp称为流式协议,udp称为数据报协议SOCK_DGRAM
# print(phone)

#2、插入/绑定手机卡
# phone.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)
phone.bind(('127.0.0.1', 8081))

#3、开机
phone.listen(5)  # 半连接池，限制的是请求数

#4、等待电话连接
print('start....')
conn, client_addr = phone.accept()  #（三次握手建立的双向连接，（客户端的ip，端口））
print(conn)
print(client_addr)

#5、通信：收发消息
data = conn.recv(1024)  #最大接收的字节数
print('来自客户端的数据', data)
conn.send(data.upper())

# import time
# time.sleep(500)
#6、挂掉电话连接
conn.close()

#7、关机
phone.close()

5.4.2 客户端

import socket
# socket.AF
#1、买手机
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print(phone)
#2、拨电话
phone.connect(('127.0.0.1', 8081))  # 指定服务端ip和端口

#3、通信：发收消息
phone.send('hello'.encode('utf-8'))
# phone.send(bytes('hello',encoding='utf-8'))
data = phone.recv(1024)
print(data)

# import time
# time.sleep(500)
#4、关闭
phone.close()

5、5 基于TCP协议的套接字编程(循环)

5.5.1 服务端

import socket

#1、买手机
phone = socket.socket(socket.AF_INET,
                      socket.SOCK_STREAM)  #tcp称为流式协议,udp称为数据报协议SOCK_DGRAM
# print(phone)

#2、插入/绑定手机卡
# phone.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)
phone.bind(('127.0.0.1', 8080))

#3、开机
phone.listen(5)  # 半连接池，限制的是请求数

#4、等待电话连接
print('start....')
while True:  # 连接循环
    conn, client_addr = phone.accept()  #（三次握手建立的双向连接，（客户端的ip，端口））
    # print(conn)
    print('已经有一个连接建立成功', client_addr)

    #5、通信：收发消息
    while True:  # 通信循环
        try:
            print('服务端正在收数据...')
            data = conn.recv(1024)  #最大接收的字节数，没有数据会在原地一直等待收，即发送者发送的数据量必须>0bytes
            # print('===>')
            if len(data) == 0: break  #在客户端单方面断开连接，服务端才会出现收空数据的情况
            print('来自客户端的数据', data)
            conn.send(data.upper())
        except ConnectionResetError:
            break
    #6、挂掉电话连接
    conn.close()

#7、关机
phone.close()

5.5.2 客户端1

import socket

#1、买手机
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# print(phone)
#2、拨电话
phone.connect(('127.0.0.1', 8080))  # 指定服务端ip和端口

#3、通信：发收消息
while True:  # 通信循环
    msg = input('>>: ').strip()  #msg=''
    if len(msg) == 0: continue
    phone.send(msg.encode('utf-8'))
    # print('has send----->')
    data = phone.recv(1024)
    # print('has recv----->')
    print(data)

#4、关闭
phone.close()

5.5.3 客户端2

import socket

#1、买手机
phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# print(phone)
#2、拨电话
phone.connect(('127.0.0.1', 8080))  # 指定服务端ip和端口

#3、通信：发收消息
while True:  # 通信循环
    msg = input('>>: ').strip()
    phone.send(msg.encode('utf-8'))
    data = phone.recv(1024)
    print(data)

#4、关闭
phone.close()

5、6 地址占用问题

这个是由于你的服务端仍然存在四次挥手的time_wait状态在占用地址（如果不懂，请深入研究1.tcp三次握手，四次挥手 2.syn洪水攻击 3.服务器高并发情况下会有大量的time_wait状态的优化方法）

5.6.1 方法一

# 加入一条socket配置，重用ip和端口

phone=socket(AF_INET,SOCK_STREAM)
phone.setsockopt(SOL_SOCKET,SO_REUSEADDR,1) #就是它，在bind前加
phone.bind(('127.0.0.1',8080))

5.6.2 方法二(Linux)

发现系统存在大量TIME_WAIT状态的连接，通过调整linux内核参数解决，
vi /etc/sysctl.conf

编辑文件，加入以下内容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
 
然后执行 /sbin/sysctl -p 让参数生效。
 
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间

六、Socket 抽象层

我们知道两个进程如果需要进行通讯最基本的一个前提是能够唯一标示一个进程，在本地进程通讯中我们可以使用PID来唯一标示一个进程，但PID只在本地唯一，网络中的两个进程PID冲突几率很大，这时候我们需要另辟它径了，我们知道IP层的IP地址可以唯一标示主机，而TCP层协议和端口号可以唯一标示主机的一个进程，这样我们可以利用IP地址＋协议＋端口号唯一标示网络中的一个进程。

能够唯一标示网络中的进程后，它们就可以利用Socket进行通信了，什么是Socket呢？我们经常把Socket翻译为套接字，Socket是在应用层和传输层之间的一个抽象层，它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用已实现进程在网络中通信。

Socket起源于UNIX，在Unix一切皆文件哲学的思想下，Socket是一种"打开—读/写—关闭"模式的实现，服务器和客户端各自维护一个"文件"，在建立连接打开后，可以向自己文件写入内容供对方读取或者读取对方内容，通讯结束时关闭文件。

七、模拟ssh远程执行命令

7、1 服务端

from socket import *
import subprocess

server = socket(AF_INET, SOCK_STREAM)

server.bind(('127.0.0.1', 8000))
server.listen(5)

print('start...')
while True:
    conn, client_addr = server.accept()

    while True:
        print('from client:', client_addr)

        cmd = conn.recv(1024)
        if len(cmd) == 0: break
        print('cmd:', cmd)

        obj = subprocess.Popen(cmd.decode('utf8'),  # 输入的cmd命令
                               shell=True,  # 通过shell运行
                               stderr=subprocess.PIPE,  # 把错误输出放入管道，以便打印
                               stdout=subprocess.PIPE)  # 把正确输出放入管道，以便打印

        stdout = obj.stdout.read()  # 打印正确输出
        stderr = obj.stderr.read()  # 打印错误输出

        conn.send(stdout)
        conn.send(stderr)

    conn.close()

server.close()

7、2 客户端

import socket

client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

client.connect(('127.0.0.1', 8000))

while True:
    data = input('please enter your data')
    client.send(data.encode('utf8'))
    data = client.recv(1024)

    print('from server:', data)

client.close()

输入dir命令，由于服务端发送字节少于1024字节，客户端可以接受。

输入tasklist命令，由于服务端发送字节多于1024字节，客户端只接受部分数据，并且当你再次输入dir命令的时候，客户端会接收dir命令的结果，但是会打印上一次的剩余未发送完的数据，这就是粘包问题。

八、粘包问题

8、1 什么是粘包

注意：只有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段后一次发送出去，这样接收方就收到了粘包数据。

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

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

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

8、2 TCP发送数据的四种情况

假设客户端分别发送了两个数据包D1和D2给服务端，由于服务端一次读取到的字节数是不确定的，故可能存在以下4种情况。

服务端分两次读取到了两个独立的数据包，分别是D1和D2，没有粘包和拆包；
服务端一次接收到了两个数据包，D1和D2粘合在一起，被称为TCP粘包；
服务端分两次读取到了两个数据包，第一次读取到了完整的D1包和D2包的部分内容，第二次读取到了D2包的剩余内容，这被称为TCP拆包；
服务端分两次读取到了两个数据包，第一次读取到了D1包的部分内容D1_1，第二次读取到了D1包的剩余内容D1_2和D2包的整包。

特例：如果此时服务端TCP接收滑窗非常小，而数据包D1和D2比较大，很有可能会发生第五种可能，即服务端分多次才能将D1和D2包接收完全，期间发生多次拆包。

8、3 粘包的两种情况

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

8.3.1 服务端

# _*_coding:utf-8_*_
__author__ = 'nickchen121'
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()

8.3.2 客户端

# _*_coding:utf-8_*_
__author__ = 'nickchen121'
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('feng'.encode('utf-8'))

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

8.3.3 服务端

# _*_coding:utf-8_*_
__author__ = 'nickchen121'
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(10)  # 下次收的时候,会先取旧的数据,然后取新的

print('----->', data1.decode('utf-8'))
print('----->', data2.decode('utf-8'))

conn.close()

3.4 客户端

# _*_coding:utf-8_*_
__author__ = 'nickchen121'
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 feng'.encode('utf-8'))

8、4 补充问题一：为何TCP是可靠传输，udp是不可靠传输

基于TCP的数据传输请参考我的另一篇文章https://www.cnblogs.com/nickchen121/p/11027575.html，TCP在数据传输时，发送端先把数据发送到自己的缓存中，然后协议控制将缓存中的数据发往对端，对端返回一个ack=1，发送端则清理缓存中的数据，对端返回ack=0，则重新发送数据，所以TCP是可靠的
udp发送数据，对端是不会返回确认信息的，因此不可靠

8、5 补充问题二：send(字节流)和recv(1024)及sendall

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

九、解决粘包问题

9、1 解决粘包问题（low版）

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

9.1.1 服务端

import socket, subprocess

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

server.bind(('127.0.0.1', 8000))
server.listen(5)

while True:
    conn, addr = server.accept()

    print('start...')
    while True:
        cmd = conn.recv(1024)
        print('cmd:', cmd)

        obj = subprocess.Popen(cmd.decode('utf8'),
                               shell=True,
                               stderr=subprocess.PIPE,
                               stdout=subprocess.PIPE)

        stdout = obj.stdout.read()

        if stdout:
            ret = stdout
        else:
            stderr = obj.stderr.read()
            ret = stderr

        ret_len = len(ret)

        conn.send(str(ret_len).encode('utf8'))

        data = conn.recv(1024).decode('utf8')

        if data == 'recv_ready':
            conn.sendall(ret)

    conn.close()

server.close()

9.1.2 客户端**

import socket

client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

client.connect(('127.0.0.1', 8000))

while True:
    msg = input('please enter your cmd you want>>>').strip()

    if len(msg) == 0: continue

    client.send(msg.encode('utf8'))
    length = int(client.recv(1024))

    client.send('recv_ready'.encode('utf8'))

    send_size = 0
    recv_size = 0

    data = b''

    while recv_size < length:
        data = client.recv(1024)
        recv_size += len(data)

    print(data.decode('utf8'))

9.1.3 为何low

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

9、2 补充struct模块

9.2.1 简单使用

import struct
import json

# 'i'是格式
try:
    obj = struct.pack('i', 1222222222223)
except Exception as e:
    print(e)
    obj = struct.pack('i', 1222)
print(obj, len(obj))
# 'i' format requires -2147483648 <= number <= 2147483647
# b'xc6x04x00x00' 4
res = struct.unpack('i', obj)
print(res[0])
1222

9、3 解决粘包问题(Nick版)

解决粘包问题的核心就是：为字节流加上自定义固定长度报头，报头中包含字节流长度，然后一次send到对端，对端在接收时，先从缓存中取出定长的报头，然后再取真实数据。

9.3.1 使用struct模块创建报头

import json
import struct

header_dic = {
    'filename': 'a.txt',
    'total_size':
    111111111111111111111111111111111222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222223131232,
    'hash': 'asdf123123x123213x'
}

header_json = json.dumps(header_dic)

header_bytes = header_json.encode('utf-8')
print(len(header_bytes))

# 'i'是格式
obj = struct.pack('i', len(header_bytes))
print(obj, len(obj))
#223
#b'xdfx00x00x00' 4
res = struct.unpack('i', obj)
print(res[0])
# 223

9.3.2 服务端

from socket import *
import subprocess
import struct
import json

server = socket(AF_INET, SOCK_STREAM)
server.bind(('127.0.0.1', 8000))
server.listen(5)

print('start...')
while True:
    conn, client_addr = server.accept()
    print(conn, client_addr)

    while True:
        cmd = conn.recv(1024)

        obj = subprocess.Popen(cmd.decode('utf8'),
                               shell=True,
                               stderr=subprocess.PIPE,
                               stdout=subprocess.PIPE)

        stderr = obj.stderr.read()
        stdout = obj.stdout.read()

        # 制作报头
        header_dict = {
            'filename': 'a.txt',
            'total_size': len(stdout) + len(stderr),
            'hash': 'xasf123213123'
        }
        header_json = json.dumps(header_dict)
        header_bytes = header_json.encode('utf8')

        # 1. 先把报头的长度len(header_bytes)打包成4个bytes，然后发送
        conn.send(struct.pack('i', len(header_bytes)))
        # 2. 发送报头
        conn.send(header_bytes)
        # 3. 发送真实的数据
        conn.send(stdout)
        conn.send(stderr)

    conn.close()

server.close()

9.3.3 客户端

from socket import *
import json
import struct

client = socket(AF_INET, SOCK_STREAM)
client.connect(('127.0.0.1', 8000))

while True:
    cmd = input('please enter your cmd you want>>>')

    if len(cmd) == 0: continue

    client.send(cmd.encode('utf8'))

    # 1. 先收4个字节，这4个字节中包含报头的长度
    header_len = struct.unpack('i', client.recv(4))[0]

    # 2. 再接收报头
    header_bytes = client.recv(header_len)

    # 3. 从包头中解析出想要的东西
    header_json = header_bytes.decode('utf8')
    header_dict = json.loads(header_json)
    total_size = header_dict['total_size']

    # 4. 再收真实的数据
    recv_size = 0
    res = b''
    while recv_size < total_size:
        data = client.recv(1024)

        res += data
        recv_size += len(data)

    print(res.decode('utf8'))

client.close()

9、4 TCP协议粘包问题分析

1.nagle算法规定，TCP协议会将数据量较小、时间间隔短的数据合并为一条发送给客户端

9.4.1 服务端

from socket import *

server = socket(AF_INET, SOCK_STREAM)
server.bind(('127.0.0.1', 8080))
server.listen(5)

conn, addr = server.accept()

# 正确做法，客户端制作报头
# res1 = conn.recv(5)
# print('第一次；', res1)

# res2 = conn.recv(5)
# print('第二次；', res2)

# res3 = conn.recv(4)
# print('第三次；', res3)


# low方法+客户端的睡眠
res1 = conn.recv(1024)
print('第一次；', res1)

res2 = conn.recv(1024)
print('第二次；', res2)

res3 = conn.recv(1024)
print('第三次；', res3)

9.4.2 客户端

9.4.3 服务端

# _*_coding:utf-8_*_
__author__ = 'nickchen121'
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(10)  # 下次收的时候,会先取旧的数据,然后取新的

print('----->', data1.decode('utf-8'))
print('----->', data2.decode('utf-8'))

conn.close()

9.4.4 客户端

# _*_coding:utf-8_*_
__author__ = 'nickchen121'
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 feng'.encode('utf-8'))

十、基于UDP协议的socket套接字编程

10、1 UDP套接字简单示例

10.1.1 服务端

import socket

server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)  # 数据报协议-》UDP
server.bind(('127.0.0.1', 8080))

while True:
    data, client_addr = server.recvfrom(1024)
    print('===>', data, client_addr)
    server.sendto(data.upper(), client_addr)

server.close()

10.1.2 客户端

import socket

client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)  # 数据报协议-》UDP

while True:
    msg = input('>>: ').strip()  # msg=''
    client.sendto(msg.encode('utf-8'), ('127.0.0.1', 8080))
    data, server_addr = client.recvfrom(1024)
    print(data)

client.close()

UDP是无链接的，先启动哪一端都不会报错
UDP协议是数据报协议，发空的时候也会自带报头，因此客户端输入空，服务端也能收到

10、2 UPD套接字无粘包问题

10.2.1 服务端

import socket

server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)  # 数据报协议-》udp
server.bind(('127.0.0.1', 8080))

data, client_addr = server.recvfrom(1024)  # b'hello'==>b'h'
print('第一次：', client_addr, data)

data, client_addr = server.recvfrom(1024)  # b'world' =>b'world'
print('第二次：', client_addr, data)
#
# data,client_addr=server.recvfrom(1024)
# print('第三次：',client_addr,data)

server.close()

10.2.2 客户端

import socket

client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)  # 数据报协议-》udp

client.sendto('hello'.encode('utf-8'), ('127.0.0.1', 8080))
client.sendto('world'.encode('utf-8'), ('127.0.0.1', 8080))
# client.sendto(''.encode('utf-8'),('127.0.0.1',8080))

client.close()

UPD协议一般不用于传输大数据。
UDP套接字虽然没有粘包问题，但是不能替代TCP套接字，因为UPD协议有一个缺陷：如果数据发送的途中，数据丢失，则数据就丢失了，而TCP协议则不会有这种缺陷，因此一般UPD套接字用户无关紧要的数据发送，例如qq聊天。

10、3 qq聊天

由于UDP无连接，所以可以同时多个客户端去跟服务端通信

10.3.1 服务端

#_*_coding:utf-8_*_
__author__ = 'nick'
import socket
ip_port = ('127.0.0.1', 8081)
UDP_server_sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)  #买手机
UDP_server_sock.bind(ip_port)

while True:
    qq_msg, addr = UDP_server_sock.recvfrom(1024)
    print('来自[%s:%s]的一条消息:33[1;44m%s33[0m' %
          (addr[0], addr[1], qq_msg.decode('utf-8')))
    back_msg = input('回复消息: ').strip()

    UDP_server_sock.sendto(back_msg.encode('utf-8'), addr)

10.3.2 客户端1

#_*_coding:utf-8_*_
__author__ = 'nick'
import socket
BUFSIZE = 1024
UDP_client_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

qq_name_dic = {
    '狗哥alex': ('127.0.0.1', 8081),
    '瞎驴': ('127.0.0.1', 8081),
    '一棵树': ('127.0.0.1', 8081),
    '武大郎': ('127.0.0.1', 8081),
}

while True:
    qq_name = input('请选择聊天对象: ').strip()
    while True:
        msg = input('请输入消息,回车发送: ').strip()
        if msg == 'quit': break
        if not msg or not qq_name or qq_name not in qq_name_dic: continue
        UDP_client_socket.sendto(msg.encode('utf-8'), qq_name_dic[qq_name])

        back_msg, addr = UDP_client_socket.recvfrom(BUFSIZE)
        print('来自[%s:%s]的一条消息:33[1;44m%s33[0m' %
              (addr[0], addr[1], back_msg.decode('utf-8')))

UDP_client_socket.close()

10.3.3 客户端2

#_*_coding:utf-8_*_
__author__ = 'nick'
import socket
BUFSIZE = 1024
UDP_client_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

qq_name_dic = {
    '狗哥alex': ('127.0.0.1', 8081),
    '瞎驴': ('127.0.0.1', 8081),
    '一棵树': ('127.0.0.1', 8081),
    '武大郎': ('127.0.0.1', 8081),
}

while True:
    qq_name = input('请选择聊天对象: ').strip()
    while True:
        msg = input('请输入消息,回车发送: ').strip()
        if msg == 'quit': break
        if not msg or not qq_name or qq_name not in qq_name_dic: continue
        UDP_client_socket.sendto(msg.encode('utf-8'), qq_name_dic[qq_name])

        back_msg, addr = UDP_client_socket.recvfrom(BUFSIZE)
        print('来自[%s:%s]的一条消息:33[1;44m%s33[0m' %
              (addr[0], addr[1], back_msg.decode('utf-8')))

UDP_client_socket.close()

10.3.4 运行结果

客户端1运行结果

客户端2运行结果

十一、基于socketserver实现并发的socket套接字编程

11、1 基于TCP协议

基于tcp的套接字，关键就是两个循环，一个链接循环，一个通信循环

socketserver模块中分两大类：server类（解决链接问题）和request类（解决通信问题）

11.1.1 server类

11.1.2 request类

11.1.3 继承关系

11.1.4 服务端

import socketserver


class MyHandler(socketserver.BaseRequestHandler):
    def handle(self):
        # 通信循环
        while True:
            # print(self.client_address)
            # print(self.request) #self.request=conn

            try:
                data = self.request.recv(1024)
                if len(data) == 0: break
                self.request.send(data.upper())
            except ConnectionResetError:
                break


if __name__ == '__main__':
    s = socketserver.ThreadingTCPServer(('127.0.0.1', 8080), MyHandler, bind_and_activate=True)

    s.serve_forever()  # 代表连接循环
    # 循环建立连接，每建立一个连接就会启动一个线程（服务员）+调用Myhanlder类产生一个对象，调用该对象下的handle方法，专门与刚刚建立好的连接做通信循环

11.1.5 客户端

import socket

phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
phone.connect(('127.0.0.1', 8080))  # 指定服务端ip和端口

while True:
    # msg=input('>>: ').strip() #msg=''
    msg = 'client33333'  # msg=''
    if len(msg) == 0: continue
    phone.send(msg.encode('utf-8'))
    data = phone.recv(1024)
    print(data)

phone.close()

11.1.6 客户端1

import socket

phone = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
phone.connect(('127.0.0.1', 8080))  # 指定服务端ip和端口

while True:
    # msg=input('>>: ').strip() #msg=''
    msg = 'client11111'  # msg=''
    if len(msg) == 0: continue
    phone.send(msg.encode('utf-8'))
    data = phone.recv(1024)
    print(data)

phone.close()

11、2 基于UDP协议2.1 服务端

import socketserver


class MyHandler(socketserver.BaseRequestHandler):
    def handle(self):
        # 通信循环
        print(self.client_address)
        print(self.request)

        data = self.request[0]
        print('客户消息', data)
        self.request[1].sendto(data.upper(), self.client_address)


if __name__ == '__main__':
    s = socketserver.ThreadingUDPServer(('127.0.0.1', 8080), MyHandler)
    s.serve_forever()

11.2.2 客户端

import socket

client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)  # 数据报协议-》udp

while True:
    # msg=input('>>: ').strip() #msg=''
    msg = 'client1111'
    client.sendto(msg.encode('utf-8'), ('127.0.0.1', 8080))
    data, server_addr = client.recvfrom(1024)
    print(data)

client.close()

11.2.3 客户端1**

import socket

client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)  # 数据报协议-》udp

while True:
    # msg=input('>>: ').strip() #msg=''
    msg = 'client2222'
    client.sendto(msg.encode('utf-8'), ('127.0.0.1', 8080))
    data, server_addr = client.recvfrom(1024)
    print(data)

client.close()

11、3 socketserver源码分析

查找属性的顺序：ThreadingTCPServer->ThreadingMixIn->TCPServer->BaseServer
1. 实例化得到ftpserver，先找类ThreadingTCPServer的init，在TCPServer中找到，进而执行server_bind，server_active
2. 找ftpserver下的serve_forever，在BaseServer中找到，进而执行self._handle_request_noblock()，该方法同样是在BaseServer中
3. 执行self._handle_request_noblock()进而执行request， client_address = self.get_request()（就是TCPServer中的self.socket.accept()），然后执行self.process_request(request， client_address)
4. 在ThreadingMixIn中找到process_request，开启多线程应对并发，进而执行process_request_thread，执行self.finish_request(request， client_address)
5. 上述四部分完成了链接循环，本部分开始进入处理通讯部分，在BaseServer中找到finish_request，触发我们自己定义的类的实例化，去找init方法，而我们自己定义的类没有该方法，则去它的父类也就是BaseRequestHandler中找....

11.3.1 源码总结

基于tcp的socketserver我们自己定义的类中的
- self.server即套接字对象
- self.request即一个链接
- self.client_address即客户端地址
基于udp的socketserver我们自己定义的类中的
- self.request是一个元组（第一个元素是客户端发来的数据，第二部分是服务端的udp套接字对象），如(b'adsf', <socket.socket fd=200, family=AddressFamily.AF_INET, type=SocketKind.SOCK_DGRAM, proto=0, laddr=('127.0.0.1', 8080)>)
- self.client_address即客户端地址

查看全文

相关阅读:
Documentum常见问题1—Tomcat应用内存溢出
 Documentum常见问题3—保存搜索Saved Searches提示用户对文件柜无权限
 Request.QueryString[]和Request[]的区别
 将money转换成大写汉字
 Windows API(一) 什么是Windows API
C#将数据导出到Excel汇总
 开始—运行—命令
 手动绘制DataTable
触发器Deleted表和Inserted表
 功能强大的Regsvr32命令

原文地址：https://www.cnblogs.com/hanyi12/p/11575574.html

网络编程

一、网络架构及其演变过程

1、1 单机架构

1、2 CS架构

1、2、1 CS 架构要求

1、2、2 面试题：数据放在服务端和客户端的利与弊？

1、3 BS架构

1、3、1 两种BS架构

1、4 CS架构和BS架构的区别

二、 互联网和互联网的组成

2、1 教材版

2、2 科普版

三、大白话OSI七层协议

3、1 物理层

3、2 数据链路层

3.2.1 以太网协议

3.2.2 Mac地址

3.2.3 广播地址

3、3 网络层

3.3.1 IP协议详解

3.3.1 IP地址的两部分

3.3.2 子网掩码详解

3.3.3 IP数据包详解

3.3.4 ARP协议详解

3、4 传输层

3.4.1 TCP协议

3.4.2 UDP协议

3.4.3 TCP报文

3.4.4 TCP三次握手和四次挥手

3、5应用层

四、TCP协议的三次握手和四次挥手

4、1 背景描述

4、2常用的熟知端口号

4、3TCP概述

4、4 TCP报文首部

4、5 TCP连接的建立（三次握手）

4、6 TCP四次挥手

4、7 面试题

4.7.1 为什么客户端最后还要等待2MSL ?

4.7.2为什么建立连接是三次握手，关闭连接确是四次挥手呢？

4.7.3 如果已经建立了连接，但是客户端突然出现故障了怎么办？

五、基于TCP协议的socket套接字编程

5、1 什么是Scoket

5、2 套接字发展史及分类

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

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

5、3 套接字工作流

5.3.1 服务端套接字函数

5.3.2 客户端套接字函数

5.3.3 公共用途的套接字函数

5.3.4 面向锁的套接字方法

5.3.5 面向文件的套接字的函数

5、4 基于TCP协议的套接字编程(简单)

5.4.1 服务端

5.4.2 客户端

5、5 基于TCP协议的套接字编程(循环)

5.5.1 服务端

5.5.2 客户端1

5.5.3 客户端2

5、6 地址占用问题

5.6.1 方法一

5.6.2 方法二(Linux)

六、Socket 抽象层

七、模拟ssh远程执行命令

7、1 服务端

7、2 客户端

八、粘包问题

8、1 什么是粘包

8、2 TCP发送数据的四种情况

8、3 粘包的两种情况

8.3.1 服务端

8.3.2 客户端

8.3.3 服务端

8、4 补充问题一：为何TCP是可靠传输，udp是不可靠传输

8、5 补充问题二：send(字节流)和recv(1024)及sendall

九、解决粘包问题

9、1 解决粘包问题（low版）

9.1.1 服务端

9.1.2 客户端**

9.1.3 为何low

二、互联网和互联网的组成