前言

这几年一直在it行业里摸爬滚打，一路走来，不少总结了一些python行业里的高频面试，看到大部分初入行的新鲜血液，还在为各样的面试题答案或收录有各种困难问题

于是乎，我自己开发了一款面试宝典，希望能帮到大家，也希望有更多的Python新人真正加入从事到这个行业里，让python火不只是停留在广告上。

客户端服务端

服务器是一个软件或硬件，服务器上存放着很多数据，用于向一个或多个客户端（客户）提供所需的服务，服务器存在的唯一目的就是等待客户的请求，给这些客户服务，然后继续等待其他人的到来

客户端的主要任务则是连接服务器，提供自己的请求，获取所需服务；向服务器发送必要的数据，然后等待服务器的完成或是失败原因的反馈。

常用的客户端现在主要为PC端应用软件或是浏览器，也就是人们常说的C/S（Client/Server）客户端/服务端架构、B/S（Browser/Server）浏览器/服务端架构。但是不管是什么架构，都需要有服务器和客户端进行支持。

但是这里中除了客户端业务实现不同，主要的服务器提供的功能都是类似的。

TCP/IP

目前使用最广泛的计算机通信协议就是TCP/IP，他可以使世界范围内的计算机通过Internet的方式进行网络通信

TCP/IP是一种标准的网络协议，目前在市面上网络通信的产品大多数使用它，所以需要我们能够对该协议拥有良好的理解及掌握。

当我们在互联网中进行通信时，类似我们生活中，当你出远门将去访问你的朋友；首先需要确定的第一件事，就是他的地址；对比当前互联网中，每一台能够上网的机器都拥有自己的一个在域网中唯一的IP（192.0.0.1）地址，这个地址用来标识机器在网络中的位置。

但是，拥有了这个地址还远远不行，你的朋友可能居住在一个非常庞大的宫殿（对比服务器）中，宫殿拥有很多入口，不同的入口之间不是互相连通的，在拜访朋友时，我们还需要提前咨询好我应该从哪个大门入口进去，不然你可能要走错啦！

同样，对比我们计算机中，同一时间可能需要进行互联网传输的程序有很多，每一个程序拥有自己独立在本台机器的一个端口（PORT）号，这个端口用来更加方便的进行数据的传输及接收；远方服务器可以直接通过这个端口向程序反馈数据。

端口范围

一般的说，端口大致有65535个。也就是2的16次方，端口号是一个整数，取自于short类型

  • 0-1023：公认端口，已被一些常见服务所占有，如：http的80、443端口
  • 1024-49151：注册端口，这些端口没有特定的服务对象，不同的程序可以实际根据自己需要来定义
  • 49152-65535：这些端口经常动态分配给可能需要的服务

dns

一个TCP/IP连接是由一个IP地址及一个端口来进行维护的，有了TCP/IP，我们就可以通过浏览器、各式各样的应用软件进行网络通信了，常用的浏览器访问站点，就是在访问对应服务器的80端口。

此外，Internet早期的设计师意识到，用户记忆一长串类似123.123.123.123这样的IP地址是很困难的，尤其是当你要访问记忆的站点将越来越多的时候，这是一件痛苦的事情

于是，出现了现在DNS。DNS通俗的来说，就是可以将这一串数字形象的表示成为一个友好的连接，比如www.hello.com，DNS会记录并帮助解析这样的英文所代表的IP地址，这样用户只需要记忆这个域名即可

TCP协议介绍

网络环境错综复杂，就像我们去拜访好友，虽然说知道了地址，也知道该从哪个门进去但是还是会走错，或者说你给好友所带的水果礼物在路上丢了（对比网络中的传输数据），那么可能你在路上玩手机，没有关注这个路口是该如何正确转向

对比这个生活现象，在网络中也会有这样的事情发生，比如：路由器丢失了传输数据包，数据半道被截取篡改了（你半路被打劫了），数据包之间的顺序不对（TCP将数据流分解成一个个小的数据包进行发送），网线断了；

TCP协议在设计之初，就已经考虑到了这些情况的发生，除非是网络出现了问题，那么数据将有多层验证手段，保证他完好无损的传输到目标主机

在使用TCP协议进行通信时，客户机和目标主机之间还需要建立连接（三次握手），保证传输真正可靠，类似人们打电话一样；并且在断开时（四次断开），还会有额外的验证等行为。这个也会在之后为大家来详细叙述。人们也经常称TCP协议为面向连接的协议。

在TCP协议传输的数据包中，将包含一个校验码。这个校验码是一个用来保证信息在传输过程中是否被修改过的验证代码，当数据包到达目标地址时，目标主机会验证该校验码与数据包中的数据。校验失败，则这个数据包将被省略。好比我们拜访到了朋友，但是所携带的通行证没有通过验证，那么我们也会被拒之门外。

此外，数据流的顺序在被TCP协议分解为小数据包传输时，每一个数据包都会记录一个序号。在网络中，每一个数据包达到目标地址的顺序可能不会是顺序的（运营商一处交换机要承担很多数据流通）。那么有了TCP协议所提供序号，目标主机在接收到数据之后，会按照序号将数据重新排列合并；如果出现了重复序号，之前的数据包也会被丢弃

TCP/IP四层模型由OSI模型简化而来

应用层

常见应用协议：http、smtp、ssh、sftp

传输层

TCP和UDP

网络层

IP、ICMP、IGMP

链路层

设备驱动程序及接口

  • 应用层：应用程序之间沟通控制，为主机之间提供高级协议进行网络通信；如：文件传输协议（SMTP）、电子邮件传输协议（SMTP）、网络远程访问协议（Telnet）
  • 传输层：传输层负责端对端的传输，这里的端只源主机和目的主机。在这一层的主要功能是数据格式化，数据确认和丢失重传。涉及到的协议有传输控制协议（TCP）、用户数据报协议（UDP）等
  • 网络层：提供基本的数据封包传送，让数据包可以到达目标主机，但是并不会检查数据的正确以及是否被目标主机接收，涉及到的协议有网际协议（IP）
  • 链路层：这一层主要负责：网卡设备驱动、帧同步、冲突检测、数据差错校验等工作

TCP报文

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JEa6pJmq-1634810973791)(./静态资源/TCP报文.png)]

  • Source Port：16位长度，源端口号
  • Destination Port：16位长度，目的端口号
  • Sequence Number：32位长度，封装序号
    表示在TCP发送数据时数据报文的第一个数据字节在整个通信数据流中的序号，用来维护TCP数据包的顺序。
  • Acknowledgment Number：32位长度，确认序号
    用来表示下一次所期望收到的下一个序号；因此，确认序号同行是上次已成功收到数据字节序号加1。并且，该值只有在标志位的ACK的标志位1时才有效。用来避免数据包在网络中传输过程中丢失问题。
  • Offset：4位长度，数据偏移
    通过该标志位来说明整个TCP数据包的起始位置，用来维护TCP数据包的大小
  • Reversed：6位长度，保留位；提供为未来使用
  • TCP Flags：6位长度，标志位字段；其中U、A、P、R、S、F各标示含义如下
  • U：URG，紧急比特（Urgent）；
    当URG为1时，表明该字段有效，标示该TCP数据报文优先级为高优先级，会表示刚数据包为紧急封包，会被加急传输。
  • A：ACK，确认比特（Acknowledge）
    当该值为1时确认字段才有效，代表这个封包为确认封包；当该值为0时，确认号无效
  • P：PSH，推送比特（Push function）
    如果该值为1时，代表要求对方立即传输缓冲区内的其他对应封包，不需要等待缓冲区满了之后才传输
  • R：RST，复位比特（Reset）
    当该值为1时，表示TCP连接中出现严重差错，必须释放连接，需要重新连接运输连接
  • S：SYN，同步比特（Synchronous）
    当该值为1时，表示这是一个连接请求或连接接收报文。通常带有SYN标志的封包表示要主动连接到对方的意思
  • F：FIN，终止比特（Final）
    当该值为1时，表明TCP数据已经发送结束，并要求释放传输连接
  • Windows：16位长度，滑动窗口；
    窗口字段用来控制对方发送的数据量，告知对方目前自身的缓冲区容量（Receive Buffer），当该值为0时，代表缓冲区已经额满，需要暂停接收数据。
  • Checksum：16位长度，TCP校验和
    当TCP数据将要被发送出去之前，会进行一个校验的工作，并将校验值标注在这个字段上；接收方拿到这个数据报文之后，会对该数据包进行验证，查看Checksum值是否相符；如果不符那么证明数据出现错误，需要重新发送接收。
  • Urgent Pointer：16位长度，紧急指针
    这个字段是在CODE字段内的URG值等于1时才会起作用，用来告知紧急数据所在的位置。该指针会指出在本报文段内中的紧急数据的最后一个字节的序号。
  • Options：长度可变，选项
    TCP首部可以有多大40字节的可选信息，用于把附加信息传递给终点，或用来对齐其他选项；
    目前该字段仅用于表示接收端可以接收的最大数据区段容量；若此字段不适用，表示可以使用任意数据区段的大小。该字段比较少用。
  • Padding：填充字段
    在options之后，因为TCP首部长度不一定为固定，通过该值维护整个首部长度为4字节的整数倍。

三次握手四次挥手

由于TCP协议是安全的面向连接的协议；一方在于另一方进行数据通信时，都首先在双方之间构成连接才可以，并且在通讯结束时，也需要走一定程序才可以断开

在创建TCP连接时的三次握手的目的也在于同步连接双方的序列号和确认号，并交换TCP窗口大小信息，用于之后TCP连接好了的数据通信。

以下是TCP协议图示

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dqCkfDhY-1634810973794)(./静态资源/三次握手四次挥手.png)]

三次握手

  • 第一次握手：建立连接，客户端发送连接请求报文段，将SYN位设置为1（提出连接请求）；Sequence Number为x；然后客户端进入SYN_SEND状态，等待服务器确认
  • 第二次握手：服务器接收到客户端发来的SYN报文之后，对SYN报文进行确认；确认无误后，设置Acknowledgment Number为x+1（下一次希望接收到的确认序号）；并且服务器也要向客户端发送SYN请求信息，将SYN位设置为1，Sequence Number设置为y；服务器现在将上述所有信息放到一个报文段（SYN+ACK）之后，一并发送给客户端，此此时服务器进入SYN_RECV状态
  • 第三次握手：客户端接收到服务器发来的SYN+ASK报文段，将Acknowledgment Number设置为y+1，将该ASK报文发送到服务端之后；客户端服务端所有握手数据接收发送完毕，并进入ESTABLISHED状态，完成TCP握手，可以开始正式TCP数据通信

四次挥手

  • 第一次断开：客户端（或服务端）向另外一台远端主机发送FIN报文段，表示客户端（或服务端）没有数据要继续发送了。并且客户端（服务端）进入FIN_WAIT_1状态
  • 第二次断开：服务端（或客户端）收到了另一端发来的FIN报文段，Acknowledgment Number和Sequence Number分别加1，向另一端发送ASK应答报文段；另一端继续进入FIN_WAIT_2状态；此时服务端（或客户端）没有数据需要继续发送了，可以进行连接的关闭。
  • 第三次断开：服务端（客户端）向另一端发送FIN报文段，请求关闭连接，同时进入CLOSE_WAIT状态。（连接断开的第二和第三步，也可以理解为一步）
  • 第四次断开：客户端（服务端）接收到了另一端发来的FIN报文段，向另一端发送ASK报文段确认，然后客户端（服务端）进入TIME_WAIT状态，并且另一端在接收到ASK报文段之后，也就关闭了连接。此时，客户端（服务端）等待2MSL没有收到另一端的任何回复，那么证明此时另一端连接以断开，这一端也就可以断开了。

UDP/IP

除去TCP/IP协议之外，还有另外一种协议也被广泛使用着，也就是众所周知的数据报协议（UDP）

与TCP不同，UDP协议并不完全可靠稳定。它只提供一个保证：数据被接收到之后是完整的

UDP无法保证数据是否真的可以被接收到，也不能保证数据是否会被重复接收或被丢弃，也不能保证数据被接收到之后的顺序和发送时的顺序一致

虽然看到UDP有这么多的缺陷。但是他有一个非常大的好处，不需要像TCP一样在通信时建立或断开连接。UDP不存在花费时间来做这些工作

目前DNS服务常用的就是UDP协议，另外一些具有庞大流量的业务可能也会采用UDP协议作为通信手段。

UDP也常用在流式音频和视频的社交软件，虽然UDP无法确保数据完美无损传输到目标主机，但是数据包丢弃也是小概率事件；

相较于TCP，虽然尽善尽美，但是过多的校验操作反而会导致与他人视频、语音通信的效率低下；所以，UDP协议还是有自己极大的用武之地