tcp三次握手和四次挥手
三次握手
1）第一次握手：建立连接时，客户端A发送SYN包（SYN=j）到服务器B，并进入SYN_SEND状态，等待服务器B确认。 （2）第二次握手：服务器B收到SYN包，必须确认客户A的SYN（ACK=j+1），同时自己也发送一个SYN包（SYN=k），即SYN+ACK包，此时服务器B进入SYN_RECV状态。 （3）第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK（ACK=k+1），此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据。
四次挥手
（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。 （2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。 （3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A。 （4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。
Cookie
- Cookie会被附加在每个HTTP请求中，所以无形中增加了流量。
- 由于在HTTP请求中的Cookie是明文传递的，很容易遭受到中间人的攻击，所以安全性成问题，除非用HTTPS。
- Cookie的大小限制在4KB左右，对于复杂的存储需求来说是不够用的。
- 不同的浏览器Cookie不是共享的，你在Chrome中登录了一个网站，使用Firefox还需要再次登录，因为这两个浏览器的Cookie不共享。
- 同一台机器同一个浏览器会共享同一个Cookie池，A用完浏览器后，如果不清理Cookie, B使用的时候会得到A的Cookie。
- Cookie存在本地是明文访问的，其他用户如果能访问的这个Cookie,就能看到这个Cookie的内容
- 容易遭受XSS跨站访问
- 第三方脚本追踪。网站中嵌入第三方的代码，就容易被第三方公司利用，在一些互联网巨头和广告公司中经常会使用。你在A网站浏览一些商品，在浏览B网站的时候，B网站的广告会给你推送这些类似商品的信息，这是因为A和B都嵌入了同一个第三方公司的代码，通过Cookie能追踪到你的浏览记录。
- Cookie投毒攻击，例如在一个购物网站的Cookie中包含了顾客应付的款项，攻击者将该值改小，达到少付款的目的
所以在使用Cookie的时候，需要一些额外的措施，避免收到攻击,下面是一些推荐设置：
设置合理的domain和path - 设置合适的MaxAge, 不使用时或者推出时设置为-1 - 设置HttpOnly为true - 设置SameSite - 采用https, 设置Secure为true - cookie不存储私密的东西，名称不设置直观易读的名称 - cookie进行加盐和加密 - 不设置太大的Cookie - 设置到安全较高的操作时，服务器端对cookie和客户端ID(浏览器属性、操作系统、客户端IP)进行验证，
避免被人窃取cookie
Session
1.Cookie将数据存放在客户端，并且还有4k的大小的限制，为了更好的和用户进行交互，很多编程语言的开发框架提供了session的功能。 2.Session还是基于cookie实现的(当然在禁用cookie的情况下可以在url后加后缀的方式曲折的实现)。一个session对应一个sessionid,
可以将这个sessionid作为cookie设置到客户端，服务器端建立一个 sessionid <---> session的对应结构。 浏览器将sessionid发送给客户端的时候，
服务器根据这个id得到session对象，就可以存取这个sessoin的内容。 3.可以将session放在内容中，也可以放在中心服务器如memcached、redis、mysql中，设置可以在web服务器中同步，这样可以实现有状态的session负载均衡。 4.sessionid要随机化，否则如果被人猜中的话，可以通过伪造session id冒充用户。 5.sessionid在cookie中的名称，不同的编程语言/web框架各不相同。 6.比如php使用PHPSESSID, java使用JSESSIONID, ColdFusion使用CFID & CFTOKEN, asp.net使用ASP.NET_SessionId,
通过cookie中的sessionid的名称，我们大致能推断出服务器所使用的编程语言。如果你不想暴露服务器的技术栈，你可以使用通用的名称，比如id。 7.Go中有多个第三方的session实现，最常用的是gorilla/sessions, 它可以用在其他的go的web框架中，并且有一二十个不同存储的实现，可以实现分布式的session。
jwt
Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。
osi七层
物理层: 主要定义物理设备标准,如网线的接口类型,光纤的接口类型,各种传输介质的传输速率等
数据链路层: 定义如何和让格式化数据以进行传输,以及如何让控制对物理介质的访问,这一层通常还提供错误检测和纠正,以确保数据的安全传输
物理层: 位于不同地理位置的网络中的两台主机系统之间提供链接和路径选择,Interbet的发展使得从世界站点访问信息的用户数大大增加，而网络层正是管理这种连接的层。
传输层：定义了一些传输数据的协议和端口号（WWW端口80等）
会话层：通过传输层（端口号：传输端口与接收端口）建立数据传输的通路，主要在你的系统之间发起会话或者接受会话请求（设备之间需要互相认识可以是IP也可以是MAC或者是主机名）
表示层：可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。
应用层： 是最靠近用户的OSI层，这一层为用户的应用程序（例如电子邮件、文件传输和终端仿真）提供网络服务。
http状态码
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的HTTP状态码 |
| 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict | 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 | Request-URI Too Large | 请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器无法满足Expect的请求头信息 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
| 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 |
API
什么是RPC
'远程过程调用协议' 是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。 进化的顺序: 先有的RPC,然后有的RESTful规范
谈谈你对restfull 规范的认识？
restful其实就是一套编写接口的'协议'，规定如何编写以及如何设置返回值、状态码等信息。 # 最显著的特点： # 用restful: 给用户一个url，根据method不同在后端做不同的处理 比如：post创建数据、get获取数据、put和patch修改数据、delete删除数据。 # 不用restful: 给调用者很多url，每个url代表一个功能，比如：add_user/delte_user/edit_user/ # 当然，还有协议其他的，比如： '版本'来控制让程序有多个版本共存的情况，版本可以放在 url、请求头（accept/自定义）、GET参数 '状态码'200/300/400/500 'url中尽量使用名词'restful也可以称为“面向资源编程” 'api标示' api.luffycity.com www.luffycity.com/api/
接口幂等性
'一个接口通过1次相同的访问，再对该接口进行N次相同的访问时，对资源不造影响就认为接口具有幂等性。' GET， #第一次获取结果、第二次也是获取结果对资源都不会造成影响，幂等。 POST， #第一次新增数据，第二次也会再次新增，非幂等。 PUT， #第一次更新数据，第二次不会再次更新，幂等。 PATCH，#第一次更新数据，第二次不会再次更新，非幂等。 DELTE，#第一次删除数据，第二次不在再删除，幂等。
为什么要使用django rest framework框架
# 在编写接口时可以不使用django rest framework框架， # 不使用：也可以做，可以用django的CBV来实现，开发者编写的代码会更多一些。 # 使用：内部帮助我们提供了很多方便的组件，我们通过配置就可以完成相应操作，如： '序列化'可以做用户请求数据校验+queryset对象的序列化称为json '解析器'获取用户请求数据request.data，会自动根据content-type请求头的不能对数据进行解析 '分页'将从数据库获取到的数据在页面进行分页显示。 # 还有其他组件： '认证'、'权限'、'访问频率控制
django rest framwork 框架中都有那些组件
#- 路由，自动帮助开发者快速为一个视图创建4个url www.oldboyedu.com/api/v1/student/$ www.oldboyedu.com/api/v1/student(?P<format>w+)$ www.oldboyedu.com/api/v1/student/(?P<pk>d+)/$ www.oldboyedu.com/api/v1/student/(?P<pk>d+)(?P<format>w+)$ #- 版本处理 - 问题：版本都可以放在那里？ - url - GET - 请求头 #- 认证 - 问题：认证流程？ #- 权限 - 权限是否可以放在中间件中？以及为什么？ #- 访问频率的控制 匿名用户可以真正的防止？无法做到真正的访问频率控制，只能把小白拒之门外。 如果要封IP，使用防火墙来做。 登录用户可以通过用户名作为唯一标示进行控制，如果有人注册很多账号，则无法防止。 #- 视图 #- 解析器 ，根据Content-Type请求头对请求体中的数据格式进行处理。request.data #- 分页 #- 序列化 - 序列化 - source - 定义方法 - 请求数据格式校验 #- 渲染器
https建立连接过程
1.客户端发送请求到服务器端 2.服务器端返回证书和公开密钥，公开密钥作为证书的一部分而存在 3.客户端验证证书和公开密钥的有效性，如果有效，则生成对称密钥并使用公开密钥加密发送到服务器端 4.服务器端使用私有密钥解密数据，并使用收到的对称密钥加密数据，发送到客户端 5.客户端使用对称密钥解密数据 6.SSL加密建立………
TCP和UDP
1.TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的，即发送数据之前 不需要建立连接 2.TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失， 不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付 3.TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向 报文的，UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低 4.每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的 交互通信 5.TCP首部开销20字节;UDP的首部开销小，只有8个字节 6.TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
传输层协议`：TCP、UDP、SCTP
网络层协议`：IP、ARP、RARP、ICMP、IGMP、OSPF
应用层协议`：http，FTP、SMTP、RIP、DNS