网络协议

网络协议

HTTP协议

HTTP协议理解

HTTP是一个属于应用层的面向对象的协议。HTTP1.0是基于请求与响应模式的、无状态、无连接的协议。

  • 无状态指：无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
  • 无连接指：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。

后来增加了HTTP1.1版本协议，HTTP1.0和HTTP1.1的主要区别：

  • 长连接 : 在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。HTTP 1.1起，默认使用长连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有非流水线方式和流水线方式 。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。
  • 错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
  • 缓存处理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
  • 带宽优化及网络连接的使用 :HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

为了安全有了HTTPS协议，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议。预防运营商劫持一个可用办法就是这个。

HTTP协议详解之URL篇

HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：http://host[":"port][abs_path]
例如：
1.输入：www.guet.edu.cn
浏览器自动转换成：http://www.guet.edu.cn/
2.http:192.168.0.116:8080/index.jsp

HTTP协议详解之请求篇

  • 请求组成

    • http请求由三部分组成，分别是：请求行、消息报头、请求正文

    • 请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：Method Request-URI HTTP-Version
      例如：

      GET /sample.jsp HTTP/1.1

      根据HTTP标准，HTTP请求可以使用多种请求方法。例如：HTTP1.1支持7种请求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet应用中，最常用的方法是GET和POST。
      URL完整地指定了要访问的网络资源，通常只要给出相对于服务器的根目录的相对目录即可，因此总是以“/”开头，最后，协议版本声明了通信过程中使用HTTP的版本。

    • 请求头(Request Header)】包含许多有关的客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正文的长度等。

      # 示例
Accept:image/gif.image/jpeg.*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
Accept-Encoding:gzip,deflate.

    • 请求头和请求正文之间是一个空行，这个行非常重要，它表示请求头已经结束，接下来的是请求正文。
      例如：
      下面是一个HTTP请求的例子：

      GET /sample.jsp HTTP/1.1
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=jinqiao&password=1234

  • http协议请求类型

    请求类型 说明
    GET： 该请求会向数据库发索取数据的请求，从而来获取信息，该请求就像数据库的select操作一样，只是用来查询一下数据，不会修改、增加数据，不会影响资源的内容，即该请求不会产生副作用。无论进行多少次操作，结果都是一样的。
    PUT： 该请求是向服务器端发送数据的，从而改变信息，该请求就像数据库的update操作一样，用来修改数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次PUT操作，其结果并没有不同。
    POST： 该请求同PUT请求类似，都是向服务器端发送数据的，但是该请求会改变数据的种类等资源，就像数据库的insert操作一样，会创建新的内容。几乎目前所有的提交操作都是用POST请求的。
    DELETE： 该请求顾名思义，就是用来删除某一个资源的，该请求就像数据库的delete操作。
    OPTIONS： 返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。
    HEAD： 向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
    TRACE： 回显服务器收到的请求，主要用于测试或诊断。
    CONNECT： HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

get和post的区别

  • get重点在从服务器上获取资源，post重点在向服务器发送数据；
  • get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用”?”连接，多个请求数据间用”&”连接，这个过程用户是可见的；
    post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的；
  • Get传输的数据量小，因为受URL长度限制，但效率较高；
    Post可以传输大量数据，所以上传文件时只能用Post方式；
  • get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等；
    post较get安全性较高；
  • get方式只能支持ASCII字符，向服务器传的中文字符可能会乱码。
    post支持标准字符集，可以正确传递中文字符。

HTTP协议详解之应答篇

在接收和解释请求消息后，服务器返回一个HTTP响应消息。
HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

  • 状态行，类似与请求行，HTTP-Version Status-Code Reason-Phrase（状态码文本）
    例如

    HTTP/1.1 200 OK

    HTTP应答码也称为状态码，它反映了Web服务器处理HTTP请求状态。
    1XX－信息类(Information),表示收到Web浏览器请求，正在进一步的处理中
    2XX－成功类（Successful）,表示用户请求被正确接收，理解和处理例如：200 OK
    3XX-重定向类(Redirection),表示请求没有成功，客户必须采取进一步的动作。
    4XX-客户端错误(Client Error)，表示客户端提交的请求有错误
    例如：404 NOT Found，意味着请求中所引用的文档不存在。
    5XX-服务器错误(Server Error)表示服务器不能完成对请求的处理：如 500
    对于我们Web开发人员来说掌握HTTP应答码有助于提高Web应用程序调试的效率和准确

  • 响应头(Response Header)响应头也和请求头一样包含许多有用的信息，例如服务器类型、日期时间、内容类型和长度等：

    # 示例
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:13:33 GMT
Content-Type:text/html
Last-Moified:Mon,6 Oct 2003 13:23:42 GMT
Content-Length:112

  • 响应正文就是服务器返回的HTML页面，响应头和正文之间也必须用空行分隔

HTTPS协议

在互联网安全通信方式上，目前用的最多的就是https配合ssl和数字证书来保证传输和认证安全了。本文追本溯源围绕这个模式谈一谈。

名称解释

  • https：在http(超文本传输协议)基础上提出的一种安全的http协议，因此可以称为安全的超文本传输协议。http协议直接放置在TCP协议之上，而https提出在http和TCP中间加上一层加密层。从发送端看，这一层负责把http的内容加密后送到下层的TCP，从接收方看，这一层负责将TCP送来的数据解密还原成http的内容。

  • SSL(Secure Socket Layer)：是Netscape公司设计的主要用于WEB的安全传输协议。从名字就可以看出它在https协议栈中负责实现上面提到的加密层。因此，一个https协议栈大致是这样的：

    201012272252113787

  • 数字证书：一种文件的名称，好比一个机构或人的签名，能够证明这个机构或人的真实性。其中包含的信息，用于实现上述功能。

  • 加密和认证：加密是指通信双方为了防止铭感信息在信道上被第三方窃听而泄漏，将明文通过加密变成密文，如果第三方无法解密的话，就算他获得密文也无能为力；认证是指通信双方为了确认对方是值得信任的消息发送或接受方，而不是使用假身份的骗子，采取的确认身份的方式。只有同时进行了加密和认真才能保证通信的安全，因此在SSL通信协议中这两者都被应。

【备注：】
因此，这三者的关系已经十分清楚了：https依赖一种实现方式，目前通用的是SSL，数字证书是支持这种安全通信的文件。另外有SSL衍生出TLS和WTLS，前者是IEFT将SSL标准化之后产生的（TSL1.0），与SSL差别很小，后者是用于无线环境下的TSL。

基于TCP/IP四层模型，SSL层加密是在应用层和传输层之间

HTTPS图解

HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图。

2011082417242348

　　1. 客户端发起HTTPS请求
　　这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

　　2. 服务端的配置
　　采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

　　3. 传送证书
　　这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

　　4. 客户端解析证书
　　这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

　　5. 传送加密信息
　　这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

　　6. 服务段解密信息
　　服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

　　7. 传输加密后的信息
　　这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

　　8. 客户端解密信息
　　客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

Ps：想了解更多，可参考以下文章
http 和 https 有何区别？如何灵活使用？
图解HTTP之HTTPS详解

加密描述

HTTPS一般使用的加密与HASH算法如下：
非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256

1). 对称加密（Symmetric Cryptography）
对称加密是最快速、最简单的一种加密方式，加密（encryption）与解密（decryption）用的是同样的密钥（secret key）。对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。
对称加密通常使用的是相对较小的密钥，一般小于256 bit。因为密钥越大，加密越强，但加密与解密的过程越慢。如果你只用1 bit来做这个密钥，那黑客们可以先试着用0来解密，不行的话就再用1解；但如果你的密钥有1 MB大，黑客们可能永远也无法破解，但加密和解密的过程要花费很长的时间。密钥的大小既要照顾到安全性，也要照顾到效率，是一个trade-off。

对称加密的一大缺点是密钥的管理与分配，换句话说，如何把密钥发送到需要解密你的消息的人的手里是一个问题。在发送密钥的过程中，密钥有很大的风险会被黑客们拦截。现实中通常的做法是将对称加密的密钥进行非对称加密，然后传送给需要它的人。

2). 非对称加密（Asymmetric Cryptography）
非对称加密为数据的加密与解密提供了一个非常安全的方法，它使用了一对密钥，公钥（public key）和私钥（private key）。私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人。非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥。比如，你向银行请求公钥，银行将公钥发给你，你使用公钥对消息加密，那么只有私钥的持有人—银行才能对你的消息解密。与对称加密不同的是，银行不需要将私钥通过网络发送出去，因此安全性大大提高。
目前最常用的非对称加密算法是RSA算法

虽然非对称加密很安全，但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

3). HASH算法
散列算法，又称哈希函数，是一种单向加密算法。在信息安全技术中，经常需要验证消息的完整性，散列(Hash)函数提供了这一服务，它对不同长度的输入消息，产生固定长度的输出。这个固定长度的输出称为原输入消息的”散列”或”消息摘要”(Message digest)。散列算法不算加密算法，因为其结果是不可逆的，既然是不可逆的，那么当然不是用来加密的。对某个数据包进行散列算法计算得到一个数字，称这个数值为摘要。

用途：主要用于验证，防止信息被修。具体用途如：文件校验、数字签名、鉴权协议
MD5：MD5是一种不可逆的加密算法，目前是最牢靠的加密算法之一，尚没有能够逆运算的程序被开发出来，它对应任何字符串都可以加密成一段唯一的固定长度的代码。

4). 总结
（1） 对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。
（2） 非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。
（3） 解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

数字签名算法和数字证书

之所以使用数字证书是因为，单纯使用非对称加密算法对对称加密算法加密，有安全隐患：公钥可能会被截取。

为了公钥传输的信赖性问题，第三方机构应运而生——证书颁发机构（CA，Certificate Authority）。CA 默认是受信任的第三方。CA 会给各个服务器颁发证书，证书存储在服务器上，并附有 CA 的电子签名

当客户端（浏览器）向服务器发送 HTTPS 请求时，一定要先获取目标服务器的证书，并根据证书上的信息，检验证书的合法性。一旦客户端检测到证书非法，就会发生错误。客户端获取了服务器的证书后，由于证书的信任性是由第三方信赖机构认证的，而证书上又包含着服务器的公钥信息，客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。

  1. 设有服务器 S，客户端 C，和第三方信赖机构 CA。
  2. S 信任 CA，CA 是知道 S 公钥的，CA 向 S 颁发证书。并附上 CA 私钥对消息摘要的加密签名。
  3. S 获得 CA 颁发的证书，将该证书传递给 C。
  4. C 获得 S 的证书，信任 CA 并知晓 CA 公钥，使用 CA 公钥对 S 证书上的签名解密，同时对消息进行散列处理，得到摘要。比较摘要，验证 S 证书的真实性。
  5. 如果 C 验证 S 证书是真实的，则信任 S 的公钥（在 S 证书中）

image-20220623160059063

image-20220623160326632

https://www.bilibili.com/video/BV18N411X7ty/

简单来说，我们使用浏览器的根证书来确保数字证书的真实性，数字证书来确保服务器非对称公钥的真实性，非对称公钥来确保对称密钥的保密性。

TCP协议

概述

TCP是面向连接的可靠传输协议，两个进程互发数据之前需要建立连接，这里的连接只不过是端系统中分配的一些缓存和状态变量，中间的分组交换机不维护任何连接状态信息。连接建立整个过程
如下(即三次握手协议)：

  • 首先，客户机发送一个特殊的TCP报文段；

  • 其次，服务器用另一个特殊的TCP报文段来响应；

  • 最后，客户机再用第三个特殊报文段作为响应。
    三次握手协议示意图如下：

    TCP三次握手

TCP协议的三次握手和四次挥手必须掌握

TCP报文格式

为了提供可靠的数据传输，TCP报文首部字段有较多的字段，TCP报文格式如下图：
image.png
首部主要字段说明：

  • 源和目标端口：用于多路复用/多路分解来自或送至上层应用的数据，可以这样理解，端口用来标识同一台计算机的不同进程

  • 序列号和确认号：序号是用来标识从TCP发端向TCP接收端发送的数据字节流。确认序号包含发送确认的一端所期望收到的下一个序号，因此，确认序号应该是上次已经成功收到数据字节序号加1.
    这两个字段是TCP可靠传输服务的关键部分，序列号是该报文段首字节的字节流编号(TCP把数据看成是有序的字节流，TCP隐式地对数据流的每个字节进行编号)。这样理解可能更直观，当报文被分解成多个报文段时，序列号就是报文段首字节在整个报文的偏移量。确定号指定下一个期待的字节。TCP是全双工的，假设从主机A接收到主机B的数据，则主机A填充进报文段的确认号是主机A期望从主机B收到的下一个字节序号。

    img

  • 首部长度指出了TCP首部的长度值，若不存在选项，则这个值为20字节

  • 标志位(flag)：
    URG: 紧急指针有效
    ACK：确认序号有效
    PSH：接收方应尽快将这个报文段交给应用层
    RST：重建连接
    SYN：同步序号用来发起一个连接
    FIN： 发端完成发送任务（主动关闭）

  • 数据

  • 无任何数据的TCP段也是合法的，通常用于确认和控制信息。
    【备注：】

  • TCP提供解决方式是为了使一端告诉另外一端某些“紧急数据”已经放置在普通的数据流中，让接收端对紧急数据做特别处理。此时，URG位被置为1，并且16位的紧急数据被置为一个正的偏移量，通过此偏移量与TCP首部中的序号字段相加，可以得出紧急数据的最后一个字节的序号，常见的应用有传输中断键（在通过telnet连接过程中）。

  • RST: 复位字段被用于当一个报文发送到某个socket接口而出现错误时，TCP则会发出复位报文段。常见出现的情况有以下几种：
    发送到不存在的端口的连接请求：此时对方的目的端口并没有侦听，对于UDP，将会发出ICMP不可达的
    错误信息，而对于TCP，将会发出设置RST复位标志位的数据报。
    异常终止一个连接：正常情况下，通过发送FIN去正常关闭一个TCP连接，但也有可能通过发送一个复位
    报文段去中途释放掉一个连接。在socketAPI中通过设置socket选 项SO_LINGER去关闭这种异常关闭的情况。

TCP的连接与终止过程

image-20220623163758261

TCP是因特网中的传输层协议，使用三次握手协议建立连接。当主动方发出SYN连接请求后，等待对方回答SYN+ACK[1]，并最终对对方的 SYN 执行 ACK 确认。这种建立连接的方法可以防止产生错误的连接，TCP使用的流量控制协议是可变大小的滑动窗口协议.

TCP三次握手

  • 流程

    1. 客户端发送SYN（SEQ=x）报文给服务器端，进入SYN_SEND状态。
    2. 服务器端收到SYN报文，回应一个SYN （SEQ=y）ACK(ACK=x+1）报文，进入SYN_RECV状态。
    3. 客户端收到服务器端的SYN报文，回应一个ACK(ACK=y+1）报文，进入Established状态。三次握手完成，TCP客户端和服务器端成功地建立连接，可以开始传输数据了。

  • 为什么要三次握手

    三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

    第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常

    第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常

    第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

    所以三次握手就能确认双方收发功能都正常，缺一不可。

TCP四次挥手

  • 流程

    TCP四次挥手

    1. 某个应用进程首先调用close，称该端执行“主动关闭”（active close）。该端的TCP于是发送一个FIN分节，表示数据发送完毕
    2. 接收到这个FIN的对端执行 “被动关闭”（passive close），这个FIN由TCP确认注意：FIN的接收也作为一个文件结束符（end-of-file）传递给接收端应用进程，放在已排队等候该应用进程接收的任何其他数据之后，因为，FIN的接收意味着接收端应用进程在相应连接上再无额外数据可接收。
    3. 一段时间后，接收到这个文件结束符的应用进程将调用close关闭它的套接字。这导致它的TCP也发送一个FIN
    4. 接收这个最终FIN的原发送端TCP（即执行主动关闭的那一端）确认这个FIN。

无论是客户还是服务器，任何一端都可以执行主动关闭。通常情况是，客户执行主动关闭，但是某些协议，例如，HTTP/1.0却由服务器执行主动关闭。

  • 为什么要四次挥手

    任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。两次握手就可以释放一端到另一端的 TCP 连接，完全释放连接一共需要四次握手。

TCP连接的超时问题

完成一个TCP连接，中间涉及到一个超时的问题，大多数unix系统的超时时限为75s，Solaris9的超时时限为240s，因此，一般认为是在75-240之间。
【引申】在具体的实现中，如何由用户自己去完成设置socket连接超时时间？
【解决方法】目前实现socket超时连接主要是通过select来完成的。具体步骤如下：

  • 建立socket
  • 将socket设置为非阻塞模式（若是阻塞模式，那么时间设置就毫无意义）
  • 调用connect去进行连接
  • 使用select检查socket是否可写，并同时判断其结果（为什么是可写？因为需要检测socket是否收到ACK。）
  • 将socket转化为阻塞模式

TCP状态图：

下图中：实线说明客户端的正常状态变迁，虚线说明服务端的正常状态变迁

544465b00200001s

深刻理解上面状态图对于编写基于TCP/IP的应用直观重要，尤其是在链接不正常时，非常有助于定位问题所在。
详解请参考：【Unix 网络编程】TCP状态转换图详解

TCP与UDP的对比

157525404189924

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

TCP/IP模型与OSI7层模型的区别

155505340924326
OSI是一种理论下的模型，而TCP/IP已经被广泛应用，称为网络互联实施上的标准。

Cookie与Session

  • 为什么要用cookie
    由于http协议是一种无状态的协议（客户端和服务端互相不认识）

    Cookies是一些存储在用户电脑上的小文件。它是被设计用来保存一些站点的用户数据，这样能够让服务器为这样的用户定制内容。页面代码能够获取到Cookie值然后发送给服务器，比如Cookie中存储了所在地理位置，以后每次进入地图就可以默认定位到改地点。

  • cookie的原理
    cookie的执行原理：就是当客户端访问服务器的时候（服务器运用了cookie），服务器会生成一份cookie传输给客户端，客户端会自动把cookie保存起来，以后客户端每次访问服务器，都会自动的携带着这份cookie。

Session

  • 什么是session
    Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了session是一种特殊的cookie。cookie是保存在客户端的，而session是保存在服务端。

  • 为什么要用session
    由于cookie 是存在用户端，而且它本身存储的尺寸大小也有限，最关键是用户可以是可见的，并可以随意的修改，很不安全。那如何又要安全，又可以方便的全局读取信息呢？于是，这个时候，一种新的存储会话机制：session 诞生了

  • session原理
    当客户端第一次请求服务器的时候，服务器生成一份session保存在服务端，将该数据(session)的id以cookie的形式传递给客户端；以后的每次请求，浏览器都会自动的携带cookie来访问服务器(session数据id)。

  • Tomcat中Session是如何实现的
    首次请求生成一个叫JSessionId的cookie,然后做相应处理，后续浏览器请求都带着，服务端根据这个判断是同一个用户

posted @ 2022-06-23 17:44  Faetbwac  阅读(70)  评论(0)  编辑  收藏  举报