网络基础层

OSI七层协议

• 物理层

  • 两台物理机的通信需求，具体就是机器A往机器B发送比特流，机器B能收到比特流，主要定义了物理的标准，比如网线的类型，光纤的接口类型，传输介质和传输速率和0101的二进制数据
  • 将它们转换成电流强弱进行传输，到达目的后，在转换成0101机器码，（网卡就是工作在这层）也就是所谓的数模转换，模数转换

• 数据链路层

  • 数据链路从用来解决，在传输过程比特流的过程中出现错传，数据传输不完整的可能，它定义了如何格式化数据以进行传输，控制了对物理介质的访问，并且还提供了错误检测和纠正，以确保数据传输的可靠性
  • 讲比特数据组成成了帧（交换机工作在这层），它对帧进行解码，并且把根据帧中包含的信息，把数据发送到正确的接收方

• 网络层

  • 将网络地址翻译成物理地址，并且把数据从发送方路由到接收方，网络层也会综合考虑，发送的优先权、网络拥塞程度、服务质量、可选路由的花费，从一个网络A节点到另一个网络B的节点的最佳路径（路由器工作在这层）
  • 而它所关注的协议就是IP协议

• 传输层

  • 解决了主机间数据传输和传输质量的问题，也是OSI模型中最重要的一层，它同时也会对流量进行控制，和接收方接收数据的快慢程度，来规定适当的发送速率
  • 也会按照网络的最大尺寸，会把较强的数据包拆解，例如：以太网不能接收大于1500字节的数据包，发送方节点的传输层就会把数据拆解成较小的数据包，同时给每个小的数据包标记序列号，以便以到接收方可以进行重组
  • 相关的协议TCP协议和UDP协议

• 会话层

  • 解决了自动收发包，自动寻址的问题，建立和管理应用程序直接的通信

• 表示层

  • 解决了不同系统直接通信语法的问题

• 应用层

  • 规定了发送方和接收方必须使用固定长度的消息头，消息头必须使用某种固定的组成，而且消息头里必须记录消息体的长度等，以便以接收方可以解析正确的数据 它关注的协议是 HTTP协议

• 总结

  • 从应用层开始都会对要传输的数据头部进行处理加上本层的一些信息，最终通过物理层以太网电缆等介质将数据解析成比特流在网络中传输，数据传递到目标地址会自体而上的将之前对应成的头部
  • 解析分类出来，这些是概念性的框架，事实上的标准只有TCP/IP协议，四层架构参考模型 应用层（相当于七层模型中的应表会） 传输层 网络层 链路层（数据链路层和物理层）
• 举例：A用户发送给B用户的一条消息
  • 客户端A发送一条数据会交给网卡，TCP/IP层就发挥了相关的作用，
  • TCP层会把这次请求打包，然后携带上自己TCP层的首部，处理完了之后就会交给IP层进行处理
  • IP层收到之后就会把 上一层TCP给的数据打成一个包 然后加上自己的IP首部，处理完之后就会交给链路层
  • 数据链路层就会把 上一层IP给的数据打成一个包 然后加上自己的数据链路层首部 加上以太网的首部, 最后打包成一个可以在网络上传输的数据 交给物理层进行一个相关的传输
  • 客户端B的数据链路层收到了就会一层层的剥离，首先是数据链路层把首部剥离然后向上传递，交给网络层处理
  • IP网络层把自己的首部剥离 又交给了TCP/IP层，最终完成用户A发送数据到用户B的全过程

IP协议

• 无连接的通信协议，它是不会占用两个正在通信的计算机之间的通信线路，这样它就降低了对网络线路的需求，每条线可以同时满足许多不同计算机之间的通信需要，通过IP、消息、或者其他的数据的包

• 会被分割为比较小独立的包，然后通过因特网在计算机之前传送，IP就会把每一个包路由 到它的目的地，但是IP协议不会去做是否按照数据发送，或者包是否被破坏过，所以它也就是不可靠的，间接的也就是需要

• 它的上层协议来控制

TCP协议

• 基于字节流、面向连接、可靠的、传输层通信协议
• 数据传输时，应用层向TCP发送数据流，然后TCP把数据流分割成适当长度的报文段，而报文段的长度是受计算机连接网络、数据链路层的最大传输单元限制的
• TCP把结果包传给IP层，由IP层通过网络，把数据包传给目标节点的TCP层
• 而为了保证不丢失包，就把每一个包一个序号也就是Sequence Number，同时序号也就保证了传送到目标节点的按序处理，然后接收端的实体对已经收到的包，发回一个相应的确认，也就是ACK确认
• 如果发送端实体在合理的往返时延，没有收到确认，那么这个数据包就会被视为已丢失，然后会把这个数据包进行重传
• TCP使用了一个“基友”校验和 函数，来校验数据是否有错误，在发送和接收时都要进行校验和的计算

TCP报文头部

•  HTTP TCP 是80端口 Https TCP是443的端口 Https携带了 SSL 端口是在传输层定义出来的
•  UDP DNS 默认是53的端口
• source port   源端口 和   Destination port 目标端口 各占2个字节 TCP和UDP都会有源端口和目标端口
• Sequence Number 序号 它是占了4个字节 每个数据包对应一个序号 如果数据包失败了 可以根据序号来判断是哪个包丢失了进行重传
• Acknowledgment Number 确认号 同样占4个字节，它所期望下一个报文的下一个序号
• offset 数据偏移 由于头部有可选字段，长度不固定，它指出TCP报文数据距离TCP报文的起始处有多远
• Reserved 保留域 保留今后使用的 一般情况下会标记为0
• TCP flag 控制位 主要是由八个标记位来组成 ，每一个标记位标识一个控制功能 
  • 常见的有URG 紧急指针标志 为1时 表示紧急指针有效  报文需要紧急处理排在普通数据的前面优先处理 放在为0就忽略紧急指针
  • ACK 确认序号标志 为1是表示序号有效 为0表示报文中不含确认信息 忽略掉确认号字段
  • PSH push标志 为1表示大于push的标志 只是接收方在接收到报文段以后，尽快的把报文段给应用程序 而不是在缓冲区排队
  • RST reset 重置连接标志 用来重置用于主机崩溃或其他原因出现错误的连接 或者用于拒绝一些非法的报文段而拒绝连接请求
  • SYN 同步序列号，用于建立连接过程
  • FIN 用来表示释放连接 为1时表示发送方已经没有数据发送 也就是关闭数据流
• windows窗口 指的是滑动窗口的大小 用来告诉接收端和发送端的缓存大小 从而控制发送端发送数据的速率从而达到流量的控制
• Checksums 校验和 指的就是”基友”校验 它是对整个TCP报文段包括TCP头部和TCP数据以16位计算得到的，由发送方计算存储 接收端进行验证
• urgent pointer 紧急指针 只有当TCP flag中的URG为1的时候才有效 指出当前报文段中的字节数
• TCP Optional 可选性 长度可变定义一些其他的可选参数

TCP三次握手

• 最开始时候的首次通信，客户端和服务器都处于一个close的状态
• 假设主动打开连接的是客户端，被动打开链接的是服务器 刚开始的时候TCP服务器的进程会先创建传输控制块,时刻准备接受其他客户端的发送过来的连接请求
• 然后服务端会进入到一个listener监听的状态，客户端也会创建一个传输控制块，然后向服务器发出连接请求报文，带上了TCP报文头中的 TCP flag报文序号SYN，让它等于1，同时选择一个初始序号seq等于x,这个x等于正整数值
• 然后客户端会进入到一个syn-sent 同步已发送的状态，紧接着如果服务器同意连接会会向客户端发送一个确认报文信息 报文中包括了flag中 2个位的字段 一个是Syn 一个ACK 值设置为1 它的确认号ack 也就是x+1 同时也为了它的缓存初始化一个序列号seq=y,这个报文也是不能携带数据的，然后消耗一个序号，也就是第二次握手
• 然后服务器会进入到Syn-rcvd同步收到的状态，
• 最后当TCP客户进程收到了确认报文后，还会给服务器一个确认 ，确认报文的ACK 等于1 小的ack 是等于y+1 同时之前的序号已经被加1了 那么seq就等于x+1 三次握手结束

TCP四次挥手

• 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，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连接

UDP

• udp报文结构是由 源端口，目标端口，数据包长度，基友校验值和用户数组组成，占了8个字节
• UDP是一个非连接的协议，传输数据之前，源端和终端是没有建立连接的，如果想传输，就直接抓取来自应用程序的数据，并尽可能块的扔到网络上
• 在发送端，UDP传输的速度仅仅是受应用程序生成数据的速度，计算机的能力和传输贷款的限制
• 在接收端，UDP把每个消息段，放在队列中，应用程序每次从队列中读取一个消息段，由于传输数据不需要连接，所以也就不用维护连接状态，因此一台服务器可以向多个客户端发送
• UDP尽最大努力交付，不会保证可靠交付
• 最后udp是面向报文传输的，发送方的UDP对应用程序发下来的报文，守护后直接向下发送，既不拆分，也不会合并

TCP和UDP的区别

• 1.TCP是基于字节流，面向连接，可靠传输，UDP是面向报文，无连接，非可靠传输
• 2.TCP连接3次握手的过程 ，UDP是消息的多波发布，从单个点向多个点传输信息
• 3.TCP利用序列号保证数据有序性，到达可能无序，但是会进行排序， UDP是无序的
• 4.TCP速度较慢，因为需要创建连接 UDP速度相比较快 在视频媒体中使用广泛
• 5.从量级来讲UDP是轻量级的，体现在报文头大小，TCP 20个字节，UDP8个字节

HTTP和HTTPS的区别

1.HTTPS在HTTP的协议上加了一个SSL层，从而具备了保护交换数据隐私，以及完整性，和身份验证的功能，简单来说就是安全版的HTTP

GET和POST区别

• 从报文层面看：get请求参数是放到URL中，请求地址长度是受限制的 post请求数据是放在报文体中的
• 从数据库层面看：get请求是符合幂等性和安全性的 post是不符合的，get请求是做查询操作的，因此它不会改变数据库中原有的数据 post是会往数据库中提交数据，所以会改变数据库的数据
• 其他的层面：get可以被缓存，被存储，post是不行的

Cookie

• cookie是客户端的解决方案，它是由服务器发送给客户端的特殊信息，而这些信息以文本的形式放在客户端，在客户端每次向服务器发送请求的时候，都会带上这些特殊的信息
• 换句话说，当用户使用浏览器访问一个支持cookie的网站时候，用户会提供包括用户名在内的个人信息，并且提交到服务器，紧接着服务器会向客户端回传相应的文本的，同时也会向客户端回传这些信息，这些信息也就存放在http的响应头，即response head中，当用户端接收到来自服务端的
• Cookie的发送过程大概分四步
  • 1.首先客户端发送一个http请求到服务端
  • 2.服务端发送一个http响应到客户端，其中是包括Set-Cookie头部
  • 3.客户端再发送一个http请求到服务端，携带上Cookie头部
  • 4.服务端再发送一个http响应到客户端

• Session

  • session是服务端的机制，服务器是使用了一种类似散列表的结构来保存信息
  • 当服务端要被某一个请求创建一个session的时候，服务器会首先检查这个请求里是否已经包含了一个session的标识，也就是session id,如果有就把它检索出来使用
  • 如果检索不到，就可能会新建一个，如果客户端请求不包含session id 就会为这个客户端创建一个session 并且生成一个和它相关联的 session id
  • Session的实现方式主要是2种：
    • 1.使用cookie来实现，服务器给每一个session 分配一个唯一的J-session 然后通过cookie发送给客户端，当客户端发起新的请求时，会在请求头中携手这个j-session id
      • 这样服务器就可以找到对应客户端的session
    • 2.使用URL回写：服务器在发送给浏览器页面的所有链接中，都携带J-session的参数，这样不管点的是哪个链接都会把session id 带回给服务器

Cookie和Session的区别

• 1.cookie数据是存在客户端的浏览器上的，session数据是存放在服务器上的
• 2.cookie不是很安全，别人可以分析存放在本地的cookie,然后进行cookie欺骗， 如果考虑安全应该使用session
• 3.session会在一定时间内保存到服务器上，当访问增多，可能会占用服务器的性能, 如果考虑服务器的开销应该使用cookie

SSL握手过程

• SSL是TSL的前身
• TCP三次握手之后就会告诉服务端TSL的版本以及支持的加密套件也就是不同的加密算法组合然后生成一个随机数发送给服务端
• 服务端在收到客户端的发送请求之后，就会给客户端发送响应报文，在响应报文里面会确认TSL支持的版本和加密套件，并且也生成一个随机数发送给客户端，
• 紧接着服务器还会再发出一个响应来出示自己的证书，和公钥，这样客户端就可以根据自己信任的证书列表来确认这个服务器是否可信，当然如果服务器也需要客户端的证书也会在此次的响应体中体现出来，比如登录网银
• 客户端在收到这个响应之后会生成第三个随机数，也叫作预主秘钥，这个随机数是通过从服务端那里收到的公钥加密而来的，然后发送给服务器，服务器就知道用商议好的算法和秘钥进行数据加密 TSL握手成功