网络基础总结

1、网络分层
    

TCP的四层：
    1、应用层： 规定向用户提供应用服务时通讯协议。 如DNS
    2、传输层： 提供处于网路链接中两台计算机之间的数据传输所使用的协议。在传输层有两个性质不一样的协议TCP和UDP
    3、网络层： 规定了数据经过怎么样的传输路线到对方计算机传送给对方。如IP协议
    4、链路层： 用来处理链接网络硬件的部分，包括操做系统、硬件设备的驱动、网卡等

2、TCP
1.简介
    TCP是传输控制协议，基于TCP的应用层有HTTP、SMTP、FTP协议等
2.特色
 面向链接、面向字节流、全双共通道、可靠。
      面向链接：使用TCP传输数据前，必须先创建TCP链接，传输完成后在释放链接
      全双共通道：创建TCP链接后，通讯双方都能发送数据
      可靠：经过TCP链接传送的数据：不丢失、无差错、不重复、按序到达
      面向字节流：数据以流的形式进行传输
    3.优缺点
      优势：数据传输可靠
      缺点：效率慢（因需创建链接、发送确认包等）
    4.创建链接  3次握手
      第一次握手：客户端向服务器发送一个链接请求的报文段。报文段信息包括：同步标志位(SYN)设为一、随机选择一个起始序号(seq)为x、不携带数据。客户端进入同步已发送状态(SYN_SEND),等待服务器的确认
      第二次握手：服务器收到请求链接报文段后，若赞成创建链接，则向客户端发回链接确认的报文段。报文段信息包括：同步标志位(SYN)设为一、确认标记位(ACK)为一、随机选择一个起始序号(seq)为y、确认号字段(ack)为x+一、不携带数据。服务器进入同步已接受状态(SYN_RCVD)
      第三次握手：客户端收到确认报文字段后，向服务器再次发出链接确认报文段。报文段信息包括：确认标记位(ACK)为一、序号(seq)为x+一、确认号字段(ack)为y+一、可携带数据。客户端、服务段都进如已建立状态，可开始发送数据

    注意：成功进行TCP的三次握手后，就创建一条TCP链接，可传送应用层数据。
        由于TCP提供的全双工通讯，故通讯双发的应用进程在任什么时候候都能发送数据。三次握手期间，任何一次未收到对面的回复，则都会重发。
    5.为何TCP创建链接须要三次握手？
        防止服务器端因接收了早已失效的链接请求报文，从而一只等待客户端请求，最终致使造成死锁、浪费资源。
        描述以下：
            a.客户端发出的第一个链接请求报文段无丢失，而是在某个网络结点长时间滞留了，致使延误到链接释放后的某个时间才到达服务器。
            b.致使延误到链接释放后的某个时间才到达服务器
            c.这是一个早已失效的报文段，可是服务器不知道，服务器收到此失效的链接请求报文段后，就误觉得是客户端再次发出的一个新的请求，因而向客户端
              发出了确认报文段，赞成创建TCP链接
            d.假设不采用“三次握手”，即服务器发出确认报文段后，TCP链接就创建了，但因为客户端并没有发出创建链接的请求，所以不会向服务器发送数据，因对                于客户端来讲，该报文已失效了，可是服务器却觉得新的TCP链接已创建，因而一直等待客户端发送数据，即死锁状态
            e.创建链接= 采用“三次握手”，即关键是第三次握手。
            f.在上面的状况，客户端不会向服务器的确认报文信息，再次发出确认。服务器因为收不到客户端的确认信息，即知道客户端并没有要求创建TCP链接，故                服务器不会一直等待客户端发送数据，即不会造成死锁状态
        其余的：SYN洪泛滥：服务器的TCP资源分配时刻=完成第二次握手时，而客户端的TCP资源分配时刻 = 完成第三次握手时，这使得服务器易于受到SYN洪泛攻          击，即同时多个客户端发起链接请求，从而需进行多个请求的TCP链接资源分配。
    6.断开须要四次挥手
        在通讯结束后，双方均可以释放链接，共需四次握手。
        释放TCP链接前。TCP客户端、服务器都处于已建立状态（ESTABLISHED），直到客户端主动关闭TCP链接
        第一次挥手：客户端向服务器发起一个链接释放的报文段（中止在发送数据）。报文段信息：终止控制(FIN)设为一、报文段序号，设为前面传送数据最后一个            字节的序号加1（seq = u）,可携带数据（FIN = 1的报文几时不携带数据也消耗一个序号）。客户端进入终止等待1状态。（FIN-WAIT-1）
        第二次握手：服务器收到链接释放报文段后，则向客户端发回链接释放确认的报文段。报文段信息：确认标记位设为1: ACK=一、报文段序号，设为前面传送            数据最后一个字节的序号加1（seq = v），确认号字段设为：ack= u+1。服务器进入关闭等待状态（CLOSE-WAIT）,客户端收到服务器的确认后，进入            终止等待2状态（FIN-WAIT-2），等待服务器发出释放链接请求。至此，客户端->服务器的TCP链接已断开，即TCP链接处于半关闭的状态，即客户端->            服务器断开，但服务器->客户端未断开
        第三次握手：若服务器已无要向客户端发送数据，则发出释放链接的报文段。报文段信息：终止控制(FIN)设为一、确认标记位设为1：ACK=1，报文段序号，            设为（seq = w）,重复上次已发送的确认号字段设为：ack = u+一、可携带数据（FIN = 1的报文即便不携带数据也消耗一个序号）。服务器进入最后确            认状态（LAST-ACK）
        第四次握手：客户端收到链接释放报文段后，则向服务器发回链接释放确认的报文段。报文段信息：确认标记位设为1:ACK=一、                                报文段序号：seq = u + 一、确认号字段为：ack = w + 一、可携带数据（FIN = 1的报文几时不携带数据也消耗一个序号）。 客户端进入等待时间状            态（TIME-WAIT），服务器进入关闭状态（COLSE），此时TCP链接还未释放，必须通过时间等待计时器设置的时间2MSL后，客户端才进入链接关闭状态            （CLOSED），即服务器进入关闭状态比客户端要早一些。

    7.为何TCP释放链接需4次挥手？
        为了保证通讯双方都能通知对方。需释放和断开链接。
        当主机1发出“释放链接请求”、主机2返回“确认释放链接”信息时，只表示主机1已无数据要发送到主机2，但主机2仍是能够发送数据给主机1，主机1仍是能够          接受主机2的数据，即单向断开    
        当主机2也发送了“释放链接请求”、主机1返回“确认释放链接”信息时，表示主机2已无数据要发送到主机1，此时双发都没法通讯，即TCP链接才算真正释放          （双向）

    八、为何客户端关闭链接前要等待2MSL时间？
        即TIME-WAIT状态的做用是什么？MSL = 最长报文寿命（Maximum Segment Lifttime）
        缘由1:为了保证客户端发送的最后一个请求链接释放确认报文能到达服务器，从而使得服务器能正常释放链接。解析：以下：
             a.客户端发送的最后一个链接释放确认报文可能会丢失，当服务器收不到最后一个链接释放确认报文时，则不会进入关闭状态，但会超时重发，链接释放报文。    
             b.假设：客户端不等待2MSL时间就直接进行关闭状态（CLOSED），当最后一个链接释放确认报文丢失、服务器重发链接释放报文时，客户端则没法接收到服务器从新发送的链接释放报文时，客户端则没法接收到服务器从新发送的链接释放报文，所以也不会发送链接释放确认报文段，最终致使服务没法进入关闭状态（CLOSED）。
            c。客户端发送最后一个链接释放确认后哦，先等待2MSL时间，在进入关闭状态（CLOSE），此时客户端则接收到服务器从新发送的链接释放报文，从而发送链接释放确认报文段，会从新启动2MSL计时器，使得服务器能正常进入关闭状态（CLOSED）
        缘由2:防止上文提到的早已失效的链接请求报文出如今本链接中，客户端发送了最后一个链接释放请求确认报文后，再通过2MSL时间，则可以使本链接持续时间内所产生的全部报文段都从网络中消失。即在下一个新的链接中就不会出现早已失效的链接请求报文。、

    9.TCP无差错传输？
        相对于UDP，TCP的传输是可靠的、无差错的。
        对于发送端：每收到一个确认帧，发送窗口就向前滑动一个帧的距离，当发送窗口内无可发送的帧时（即窗口内的帧所有是已发送但未收到确认的帧），发送方就会中止发送，直到收到接收方发送的确认帧使窗口移动，窗口内有能够发送的帧，以后才能够继续发送。
        对于接收端：当收到数据帧后，将串口向前移动一个位置，并返回确认帧，若收到的数据落在窗口以后，则一概丢弃。

        发送窗口：定义：任意时刻，发送方维持的一组连续的、容许发送帧的帧序号。做用：对发送方进行流量控制。
        接收串口：定义：任意时刻，接收方维持的一组连续的、容许接收帧的帧序号。做用：控制可接收哪些数据，不可接收哪些数据帧；接收方只有当收到的数据的序号落入接收窗口内才容许将该数据帧手下；不然，一概丢弃。

    10.TCP和UDP的区别
        TCP：面向链接、可靠、字节流（传输形式）、传输速率慢、所需资源多、要求通讯数据可靠，首部字节在20-60
        UPD：无链接、不可靠、数据报文段（传输形式）、传输速率快、所需资源少、要求通讯速度快，首部字8个字节（由4个字段组成）

2、UDP
    1.面向无链接
    UDP是不须要和 TCP 同样在发送数据前进行三次握手创建链接的，想发数据就能够开始发送了。而且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操做。
    具体来讲： 

    a.在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增长一个 UDP 头标识下是 UDP 协议，而后就传递给网络层了

    b.在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操做

   2.不可靠性
      a.不可靠性体如今无链接上，通讯都不须要创建链接，想发就发。
     b.收到什么数据就传递什么数据，而且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。

     c.网络环境时好时坏，可是 UDP 由于没有拥塞控制，一直会以恒定的速度发送数据。即便网络条件很差，也不会对发送速率进行调整。这样实现的弊端就是在网络条件很差的状况下可能会致使丢包，可是优势也很明显，在某些实时性要求高的场景（好比电话会议）就须要使用 UDP 而不是 TCP。

   3.高效
    UDP 的头部开销小，只有八字节，相比 TCP 的至少二十字节要少得多，在传输数据报文时是很高效的。
    UDP 头部包含了如下几个数据
两个十六位的端口号，分别为源端口（可选字段）和目标端口
整个数据报文的长度
整个数据报文的检验和（IPv4 可选 字段），该字段用于发现头部信息和数据中的错误
    4.传输方式
        UDP 不止支持一对一的传输方式，一样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。

3、HTTP
    1.简介和特色
        http：超文本传输协议，完成从客户端到服务器等一些系列运做流程。web是创建在http协议上的通讯。
        特色：a.http是不保存状态的协议，既无状态协议。协议自己对于请求或响应之间的通讯状态不进行保存，所以链接双方不能知晓对方当前的身份和状态。这也是Cookie技术产生的重要缘由之一：客户端的状态管理。浏览器会根据从服务器端发送的响应报文内 Set-Cookie 首部字段信息自动保持 Cookie。而每次客户端发送 HTTP 请求，都会在请求报文中携带 Cookie，做为服务端识别客户端身份状态的标识。
             b.无链接，即交换http报文前，不须要创建HTTP链接
        http协议是TCP/IP协议的一个子集.http采用TCP做为运输层协议。
     2.http请求报文。
        http的请求报文有请求行、请求头、请求体组成
        请求行： 声明请求方法、主机域名、路径资源、协议版本
        请求头：声明客户端、服务器、等报文的部分信息
        请求体：存放需发送的数据信息
        报文结构以下：

    2.1请求行
        请求行： 声明请求方法、主机域名、路径资源、协议版本
        注意空格不能省略
    请求方法：
        GET：请求读取url标志的信息
        POST：为服务器添加信息
        HEAD：请求读取URL标志信息的首部信息
        PUT：指定的URL下添加（存储）一个文档
        DELETE：删除指定URL所标志信息
        TRACE：用于进行环回测试的请求豹纹
        CONNECT：用于代理服务器
        OPTION： 请求选项信息
    请求路径（URL的地址部分）
        定义：统一资源定位符，
        做用：表示资源位置
        组成：协议：// 主机：端口/路径
    协议版本：
        做用：定义http的版本号
        常见的有HTTP HTTP1.0 HTTP1.1 HTTP2.0 HTTP3.0
请求地址址:Request URL:https://ss1.bdstatic.com/5eN1bjq8AAUYm2zgoY3K/r/www/cache/static/protocol/https/soutu/img/camera_new_5606e8f.png
请求方法 Request Method:GET
远程地址:Remote Address:14.152.86.32:443
状态码:Status Code：304
版本:HTTP/2.0
Referrer 政策 Referrer Policy:unsafe-url
    2.1请求头
        做用：声明客户端、服务器的报文的部分信息
        使用方式：字段名：值
        经常使用的请求和响应报文的通用Header
通用字段 做用
Content-Type   请求体/响应体的类型。如text/plain、application/json
Accept  说明接收的类型，能够多个值。用,(半角号)分开
Content-Length  请求/响应体的长度，单位字节
Cache-Control  取值通常为no-cache 或 max-age=xx， xx为整数，表示该资源缓存有效期（秒）
Ttag  给当前资源的标识别，和last-nodified、If-None-Match、If-Modified-Since配合，用于缓存控制
Connection 浏览器想要优先使用的链接类型，好比 keep-alive
Date 建立报文时间
Transfer-Encoding 传输编码方式
Upgrade 要求客户端升级协议
    常见的请求头
请求首部 做用
Authorization  用于设置身份认证信息
Accept-Encoding 能正确接收的编码格式列表
Host 服务器的域名和端口号
If-Modified-Since  值为上一次服务器返回的Last-modified值，用于确认某个资源是否被更改过，没有更改返回 304（比较时间）就重缓存里面拿
If-None-Match  值为上一次服务器返回的Etag值，通常会和if-modified-since一块儿出现
User-Agent 客户端信息
Cookie
已有的cookie
Referer  表示请求引用自哪一个地址，好比你从页面A跳转到页面B时，值为页面A的地址。
Host  请求端口
TE
传输编码方式
Accept-Encoding 能正确接收的编码格式列表
Accept-Language
能正确接收的语言列表

Host: ss1.bdstatic.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: image/webp,/
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Referer: https://ss1.bdstatic.com/5eN1bjq8AAUYm2zgoY3K/r/www/cache/static/protocol/https/soutu/css/soutu.css
Connection: keep-alive
If-Modified-Since: Mon, 07 Nov 2016 07:51:11 GMT
If-None-Match: "287-540b1498e39c0"
Cache-Control: max-age=0
TE: Trailers
    2.3请求体                    
    做用：存放 需发送给服务器的数据信息
    注意： get无请求体

    3.http响应报文
        响应报文包括：状态行、响应头、响应体
        状态行： 声明协议版本、状态码描述
        响应体：声明客户端、服务器报文部分信息
        响应体： 存放需发送的数据信息

    3.1状态行
        组成： 协议版本、状态码、状态信息组成 注意：空格不能省 和（\r\n）
        状态码后面单独讲
    3.2响应头
        做用：声明客户端、服务器报文的部分信息
        使用方式： header：value
响应首部 做用
Date  服务器日期
Last-modified  资源最后被修改时间
ETag 资源标识
Transfer-Encoding  取值通常为chunked，出如今Content-Lenght不能肯定的状况下，表示服务器不知道响应版本的数据大小，通常同时还会出现Content-Encoding响应头
Set-cookie  设置cookie
Location  重定向到另一个URL，如输入浏览器就输入baidu.com回车，会自动跳转到https://www.baidu.com.就是经过这个响应头控制的
Server  后台服务器

    4.http状态码
        1xx：表示信息通知，如请求收到了或正在处理
        2xx：表示成功，如接收或者直到了
        3xx：表示重定向，如要完成请求还必须采起进一步行动
        4xx：表示客户端端错误，请求包含语法错误/没法实现
        5xx：表示服务器，服务器不能实现一种明显无效的请求
        
        200->ok
          请求已成功，请求所但愿的响应头或数据体将随此响应返回。实际的响应将取决于所使用的请求方法。在GET请求中，响应将包含与请求的资源相对应的实体。在POST请求中，响应将包含描述或操做结果的实体。
        202-> Accepted
          服务器已接受请求，但还没有处理。最终该请求可能会也可能不会被执行，而且可能在处理发生时被禁止。    
        301 -> Moved Permanently 请求的资源已被永久移动到新的位置
           被请求的资源已永久移动到新位置，而且未来任何对此资源的引用都应该使用本响应返回的若干个URI之一。若是可能，拥有连接编辑功能的客户端应当自动把请求的地址修改成从服务器反馈回来的地址。[19]除非额外指定，不然这个响应也是可缓存的。 新的永久性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，不然响应的实体中应当包含指向新的URI的超连接及简短说明。 若是这不是一个GET或者HEAD请求，那么浏览器禁止自动进行重定向，除非获得用户的确认，由于请求的条件可能所以发生变化。 注意：对于某些使用HTTP/1.0协议的浏览器，当它们发送的POST请求获得了一个301响应的话，接下来的重定向请求将会变成GET方式。
         302 -> Found 请求的资源被临时移动到新的位置
            要求客户端执行临时重定向（原始描述短语为“Moved Temporarily”）。[20]因为这样的重定向是临时的，客户端应当继续向原有地址发送之后的请求。只有在Cache-Control或Expires中进行了指定的状况下，这个响应才是可缓存的。 新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，不然响应的实体中应当包含指向新的URI的超连接及简短说明。 若是这不是一个GET或者HEAD请求，那么浏览器禁止自动进行重定向，除非获得用户的确认，由于请求的条件可能所以发生变化。 注意：虽然RFC 1945和RFC 2068规范不容许客户端在重定向时改变请求的方法，可是不少现存的浏览器将302响应视做为303响应，而且使用GET方式访问在Location中规定的URI，而无视原先请求的方法。[21]所以状态码303和307被添加了进来，用以明确服务器期待客户端进行何种反应。
        304 -> Not Modified
            表示资源在由请求头中的If-Modified-Since或If-None-Match参数指定的这一版本以后，不曾被修改。在这种状况下，因为客户端仍然具备之前下载的副本，所以不须要从新传输资源。
        400 -> Bad Request
            明显的客户端错误（例如，格式错误的请求语法，太大的大小，无效的请求消息或欺骗性路由请求），服务器不能或不会处理该请求。
        401 -> Unauthorized 请求须要验证用户
        403 -> Forbidden 不容许访问该地址
            HTTP 403 服务器已经理解请求，可是拒绝执行它。与401响应不一样的是，身份验证并不能提供任何帮助，并且这个请求也不该该被重复提交。若是这不是一个HEAD请求，并且服务器但愿可以讲清楚为什么请求不能被执行，那么就应该在实体内描述拒绝的缘由。固然服务器也能够返回一个404响应，假如它不但愿让客户端得到任何信息。
        404 -> not Found 
            求失败，请求所但愿获得的资源未被在服务器上发现，但容许用户的后续请求。[35]没有信息可以告诉用户这个情况究竟是暂时的仍是永久的。假如服务器知道状况的话，应当使用410状态码来告知旧资源由于某些内部的配置机制问题，已经永久的不可用，并且没有任何能够跳转的地址。404这个状态码被普遍应用于当服务器不想揭示到底为什么请求被拒绝或者没有其余适合的响应可用的状况下。 
        408 -> Request Timeout 请求超时
            客户端没有在服务器预备等待的时间内完成一个请求的发送，客户端能够随时再次提交这一请求而无需进行任何更改
        500 -> 服务端内部错误       
            通用错误消息，服务器遇到了一个不曾预料的情况，致使了它没法完成对请求的处理。没有给出具体错误信息。 
        502 -> bad gateway
            网关或者代理工做的服务器尝试执行请求时，从上游服务器接收到无效的响应。

    5.http2.0 /http3.0         http2.0