web和计算机网络基础理解

Web

Http

1. http:是超文本传输协议，是以明文方式发送信息，如果黑客截取了Web浏览器和服务器之间的传输保温，就可以直接获得其中的信息。

• 原理：
  1. 客户端的浏览器先要通过网络与服务器建立连接，该连接是通过tcp来完成的，一般tcp连接的端口号是80建立连接的，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（url）、协议版本号、后面是mime信息包括请求修饰符、客户机信息和许可内容
  2. 服务器接收到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或者错误的代码，后面是mime信息包括服务器信息、实体信息和可能的内容 。

2. http方法有哪些？
   1. get：用于请求访问已经被uri识别的资源，可以通过Url传参给服务器
   2. post:用于传输信息给服务器
   3. put：传输文件，报文主体中包含文件内容，保存到对应uri位置
   4. delete：删除文件，删除对应url位置的文件
   5. head:获得报文首部。只是不返回报文主体，一般用于验证uri是否有效
   6. options：查询相应uri支持的http方法
3. get和put方法的区别
   1. get重点是从服务器上获取资源，post重点在向服务器发送数据；
   2. get传输数据是通过url请求，以field（字段）=value的形式，置于url后，并用?连接，多个请求数据间用&连接，这个过程用户是可见的；而post传输数据通过hhtp的post机制，将字段与对应值封存在请求实体中实体中发送给服务器，这个过程对用户是不可见的；
   3. get传输的数据量小，因为受url长度限制，但效率高；而post可以传输大量数据，所以上传文件时只能用post方式；
   4. get是不安全的，因为url是可见的，可能会泄露私密信息，密码等；post相比get安全性高；
   5. get方式只能支持ascii字符，向服务器传的中文字符可能会乱码； 而post支持标准版=字符集，可以正确传递中文字符。
4. 常见的http相应的状态码
   — 200：请求被正常处理
   — 204：请求被受理但没有资源可以返回
   — 206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行get方法，相应报文中通过conteng-range指定范围的资源。
   — 301：永久性重定向
   — 302：临时性重定向
   — 303：与302状态码有相似功能，只是希望客户端在请求一个Url的时候，能通过get方法重定向搭配另一个uri上
   — 304：发送附带条件的请求时，条件不满足时返回，与重定向无关
   — 307：临时重定向，只是强制要求使用post方法
   — 400：请求报文语法有误，服务器无法识别
   — 401：请求需要认证
   — 403：请求的对应资源禁止被访问
   — 404：服务器无法找到对应资源
   — 500：服务器内部错误
   — 503：服务器正忙

http的长连接和短连接

HTTP1.1规定了默认长度连接，数据传输完成了保持TCP连接不断开(不四次握手)，等待在同域名下继续用这个通过传输数据；相反的就是短连接

1. http1.0,1.1的区别

   • http1.0：规定浏览器和服务器保持短暂的连接，浏览器的每次请求都需要与服务器建立一个Tcp连接，服务器处理完成后立即断开tcp连接，服务器不跟踪每个客户端也不记录过去的请求(无状态)
     这种无状态可以借助cookie/session机制来做身份认证和状态记录，但是会出现两个问题
   1. 无连接的特征导致最大的性能缺陷就是无法复用连接。每次发送请求的时候，都需要进行一次tcp连接，而tcp连接释放过程又是比较费事。所以这种无连接的特性会使得网络的利用率非常低。
   2. 队头阻塞。由于http1.0规定下一个请求必须在前一个请求响应到达之前才能发送。假设前一个请求响应一直不到达，那么下一个请求就不发送，同样的后面的请求也给阻塞了。
   • 为了解决1.0的问题，1.1出现了，对于1.1不仅继承了1.0简单的特点，还解决了1.0性能上的问题。
   1. 首先是长连接，1.1增加了一个connection字段，通过设置keep-alive可以保持http连接不断开，避免了每次客户端与服务器都要重复建立tcp连接，提高了网络的利用率。如果客户端想关闭http连接，可以在请求头中携带connection，false来告知服务器关闭请求。
   2. 支持请求管道化。基于1.1的长连接，使得请求管道化成为可能。管道化使得请求能够并行传输。就比如说，响应的主体是一个html页面，页面中包含了很多Img,这个时候keep-alive就起了很大的作用，能够进行并行发送多个请求。 http管道化可以让我们把先进先出队列从客户端迁移到服务器。

   • 但存在的问题是,1.1还是无法解决队头阻塞问题。同样管道化也存在各种各样的问题，所以很多浏览器要么根本不支持，要么就默认直接关闭，而且虽然支持管道化，但是服务器也必须进行一个一个响应的送回，并行指的就是不同的tcp连接上的http请求和响应。

   • 此外1.1还加入了缓存处理新的字段如cache-control，支持断点传输，以及增加了Host字段，使得一个服务器能够用来创建读个web站点。

https

• https：是以安全为目标的http通道，是http的安全版。https的安全基础是sll.ssl协议位于tcp/ip协议与各种应用协议之间，为数据通讯提供安全支持。
• 设计目标：
  1. 数据保密性：保证数据内容在传输的过程中不会被第三方查看。
  2. 数据完整性：及时发现被第三方篡改的传输内容。
  3. 身份校验安全性：保证数据到大用户期望的目的地。

http和https区别

1. 首先http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
2. http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80,后者是443。
3. http的连接很简单，是无状态的。https协议是由ssl+http协议构建的可进行加密传输，比hht协议安全。其中无状态的意思就是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。

web三大组件

Servlet是用来处理客户端请求的动态资源，也就是当我们在浏览器中输入一个地址回车跳转后，请求就会被发送到对应的Servlet上进行处理。

Servlet的任务有：

1.接收请求数据：我们都知道客户端请求会被封装成HttpServletRequesr对象，里面包含了请求头、参数等各种信息。

2.处理请求：通常我们会在service,dopost,doget方法进行接收参数，并且调用业务层的方法来处理请求

3.完成响应“处理完请求后，我们一般会转发(forword)或者重定向(redirect)到某个页面，转发是HttpServletRequest中的方法，重定向是HttpServletResponse中的方法，两者是有很大区别的

Servlet的创建：Servlet可以在以第1次接收时被创建，也可以在在服务器启动时就被创建，这需要在web.xml的中添加一条配置信息，< load-on-startup>5< /load-on-startup>，当值为0或者大于0时，表示容器在应用启动时就加载这个servlet，当是一个负数时或者没有指定时，则指示容器在该servlet被请求时才加载。

servlet的生命周期方法

servlet的初始化，旨在servlet实例时候调用一次，Servlet是单例，整个服务器就只创建一个同类型Servlet

servlet的处理请求方法，在servlet被请求时，会被马上调用，每处理一次请求，就会被调用一次，

servlet销毁之前执行的方法，只执行一次，用于释放servlet占有的资源，通常servlet是没有什么可要释放的，所以该方法一般都是空

Fliter

filter与servlet在很多的方面极其相似，但是也有不同，例如filter和servlet一样都又三个生命周期方法，同时他们在web.xml中的配置文件也是差不多的、 但是servlet主要负责处理请求，而filter主要负责拦截请求，和放行。

filter四种拦截方式

1.REQUEST:直接访问目标资源时执行过滤器。包括：在地址栏中直接访问、表单提交、超链接、重定向，只要在地址栏中可以看到目标资源的路径，就是REQUEST

2.FORWOARD:转发访问执行过滤器。包括RequestDispatcher#forward()方法、< jsp:forward>标签都是转发访问；

3.INCLUDE:包含访问执行过滤器。包括RequestDispatcher#include()方法、< jsp:include>标签都是包含访问；

4.ERROR:当目标资源在web.xml中配置包括RequestDispatcher#include()方法、< jsp:include>标签都是包含访问；

url-mapping的写法
匹配规则有三种：

• 精确匹配 —— 如/foo.htm，只会匹配foo.htm这个URL
• 路径匹配 —— 如/foo/*，会匹配以foo为前缀的URL
• 后缀匹配 —— 如.htm，会匹配所有以.htm为后缀的URL*
• < url-pattern>的其他写法，如/foo/ ，/.htm ，/foo 都是不对的。

执行filter的顺序

如果有多个过滤器都匹配该请求，顺序决定于web.xml filter-mapping的顺序，在前面的先执行，后面的后执行

Listener

listener就是监听器，我们在JAVASE开发时，经常会给按钮加监听器，当点击这个按钮就会出发监听事件，调用onClick方法，本质是方法回掉。

在JavaWeb的Listener也是这么个原理，但是它监听的内容不同，它可以监听Application、Session、Request对象，当这些对象发生变化就会调用对应的监听方法。

应用域监听：
Ø ServletContext（监听Application）

¨ 生命周期监听：ServletContextListener，它有两个方法，一个在出生时调用，一个在死亡时调用；

¨ 属性监听：ServletContextAttributeListener，它有三个方法，一个在添加属性时调用，一个在替换属性时调用，最后一个是在移除属性时调用。

HttpSession（监听Session）

¨ 生命周期监听：HttpSessionListener，它有两个方法，一个在出生时调用，一个在死亡时调用；

¨ 属性监听：HttpSessioniAttributeListener，它有三个方法，一个在添加属性时调用，一个在替换属性时调用，最后一个是在移除属性时调用。

ServletRequest（监听Request）

¨ 生命周期监听：ServletRequestListener，它有两个方法，一个在出生时调用，一个在死亡时调用；

属性监听：ServletRequestAttributeListener，它有三个方法，一个在添加属性时调用，一个在替换属性时调用，最后一个是在移除属性时调用。

感知Session监听：
1：HttpSessionBindingListener监听
⑴在需要监听的实体类实现HttpSessionBindingListener接口
⑵重写valueBound()方法，这方法是在当该实体类被放到Session中时，触发该方法
⑶重写valueUnbound()方法，这方法是在当该实体类从Session中被移除时，触发该方法
2：HttpSessionActivationListener监听
⑴在需要监听的实体类实现HttpSessionActivationListener接口
⑵重写sessionWillPassivate()方法，这方法是在当该实体类被序列化时，触发该方法
⑶重写sessionDidActivate()方法，这方法是在当该实体类被反序列化时，触发该方法

cookie 和 session

• cookie的工作原理：

  1. 浏览器端第一次发送请求到服务器端
  2. 服务器端创建Cookie，该Cookie中包含用户的信息，然后将该Cookie发送到浏览器端
  3. 浏览器端再次访问服务器端时会携带服务器端创建的Cookie
  4. 服务器端通过Cookie中携带的数据区分不同的用户

• session的工作原理：

  1. 浏览器端第一次发送请求到服务器端，服务器端创建一个Session，同时会创建一个特殊的Cookie（name为JSESSIONID的固定值，value为session对象的ID），然后将该Cookie发送至浏览器端
  2. 浏览器端发送第N（N>1）次请求到服务器端,浏览器端访问服务器端时就会携带该name为JSESSIONID的Cookie对象
  3. 服务器端根据name为JSESSIONID的Cookie的value(sessionId),去查询Session对象，从而区分不同用户。
  • name为JSESSIONID的Cookie不存在（关闭或更换浏览器），返回1中重新去创建Session与特殊的Cookie
  • name为JSESSIONID的Cookie存在，根据value中的SessionId去寻找session对象
  • value为SessionId不存在**（Session对象默认存活30分钟）**，返回1中重新去创建Session与特殊的Cookie
  • value为SessionId存在，返回session对象

• cookie和session都是会话技术，cookie数据是存储到客户端，而session是存储到服务端

• 在浏览器中，cookie存储的数据大小有限 ；而session没有大小限制，跟服务端的内存有关

• cookie安全性差，可以通过拦截或本地文件可以对cookie进行攻击；而session运行在服务端，安全性高

• 如果浏览器禁用了cookie，那么cookie就不能使用，而session不能禁用

//发送cookie

        Cookie cookie = new Cookie(name,value)

        cookie.setMaxAge(秒)

        cookie.setPath()

        response.addCookie(cookie)

//获得cookie

        Cookie[] cookies = request.getCookies();

        cookie.getName();

        cookie.getValue();
Session技术：借助cookie存储JSESSIONID

    HttpSession session = request.getSession();

    setAttribute(name,value);

    getAttribute(name);

//session生命周期
    创建：第一次指定request.getSession();
    销毁：服务器关闭、session失效/过期、手动session.invalidate();
session作用范围：默认一会话中

cookie 场景：用户永久登录

实现的方法是把登录信息如账号、密码保存在cookie中，并控制cookie的有效期，下次访问时再验证cookie中的登录信息即可。

• 1.最直接的方法是把用户名和密码都保存到cookie中，下次访问时检查cookie中的用户名与密码，与数据库比较即可。这是一种比较危险的选择，一般不把密码等重要信息保存到cookie中。
• 2.把密码加密保存到cookie中，下次访问直接和数据库进行比较。
  这两种方案验证账号时都要查询数据库。
• 3.只在登录时查询一次数据库，以后访问验证登录信息是不再查询数据库。实现的方式是把账号按照一定的规则加密后，连同账号一块保存到cookie中，下次访问时只需要判断账号的 加密规则是否正确即可。 把账号保存到名为account的Cookie中，把账号连同密钥用MD1算法加密后保存到名为ssid的Cookie中。验证时验证Cookie中的账号与密钥加密后是否与Cookie中的ssid相等。

session场景：实现用户的登录

Session对应的类为javax.servlet.http.HttpSession类。每个来访者对应一个Session对象，所有该客户的状态信息都保存在这个Session对象里。Session对象是在客户端第一次请求服务器的时候创建的。Session也是一种key-value的属性对，通过getAttribute(Stringkey)和setAttribute(String key，Objectvalue)方法读写客户状态信息。Servlet里通过request.getSession()方法获取该客户的Session，request还可以使用getSession(boolean create)来获取Session。区别是如果该客户的Session不存在，request.getSession()方法会返回null，而getSession(true)会先创建Session再将Session返回。

Servlet中必须使用request来编程式获取HttpSession对象，而JSP中内置了Session隐藏对象，可以直接使用。如果使用声明了<%@page session=“false” %>，则Session隐藏对象不可用。

登录界面验证用户登录信息，如果登录正确，就把用户信息以及登录时间保存进Session，然后转到欢迎页面welcome.jsp。welcome.jsp中从Session中获取信息，并将用户资料显示出来。

Session机制决定了当前客户只会获取到自己的Session，而不会获取到别人的Session。各客户的Session也彼此独立，互不可见。

– 1.session的生命周期： 　
Session保存在服务器端。为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。

Session在用户第一次访问服务器的时候自动创建。需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session。如果尚未生成Session，也可以使用request.getSession(true)强制生成Session。

Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session“活跃（active）”了一次。

– 2.session的有效期：为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。
---- 1.Session的超时时间为maxInactiveInterval属性，可以通过对应的getMaxInactiveInterval()获取，通过setMaxInactiveInterval(longinterval)修改。
---- 2.Session的超时时间也可以在web.xml中修改。
---- 3.通过调用Session的invalidate()方法可以使Session失效。

session是从哪里来的，如何使用？

简洁版：当客户端第一次请求session对象的时候，服务器会为客户端创建一个session，并通过特殊算法算出一个session的id，用来标识该session对象。

浏览器第一次访问服务器时，会在服务器端生成一个session，有一个sessionid和他对应。tomcat生成的sessionid叫做jsessionid。
session在访问tomcat服务器httpservletrequest的getsession的时候创建的，tomcat的ManagerBase类提供创建sessionid的方法:随机数+时间+jvmid，存储在服务器内存中，tomcat的StandardManager类将session存储在内存中，也可以持久化到file，数据库，redis等。客户端只保存sessionid到cookie中，而不会保存session，session销毁只能通过invalidate或超时，关闭浏览器并不会关闭session。

session会因为浏览器的关闭而删除吗？

不会。只能通过validate或者超时。

如果客户端浏览器将cookie功能禁用，或者不支持cookie怎么办？

JavaWeb提供了另一种解决方案：url地址重写，重写的原理是将该客户seesion的id信息重写到url地址中。服务器能够解析重写后的url获取seesion的id，这样即使客户端不支持cookie，也可以使用seesion来记录用户状态。

httpservletResponse类提供了encodeURL实现URL地址重写。该方法会自动判断客户端是否支持Cookie，如果客户端支持cookie，会将url原封不动地输出来，如果客户端不支持cookie，则会将用户session的Id重写到url中。

cookie和session的区别

• 1.cookie数据是放在客户端的浏览器上，而session数据是放在服务器上。
• 2.cookie不是很安全，别人可以分析存放在本地的cokkie，考虑到安全应该使用session。
• 3.设置cookie时间可以使cookie过期，而使用session-destory（），我们将会销毁会话。
• 4.session会花一定时间保存在服务器上，当访问比较多时，会比较占用服务器的性能考虑到减轻服务器性能方面，应当使用cookie。
• 5.单个cookie保存的数据不超过4k，很多浏览器都限制一个站点最多保存20个cookie，而session对象没有对存储的数据的数据量的控制，其中可以保存更为复杂的数据类型。

重定向和转发的区别及应用场景分析

1.转发只能将请求转发给同一个WEB应用中的组件；而重定向不仅仅可以重定向到当前应用程序中的其他资源，还可以重定向到同一个站点上的其他应用程序中的资源，甚至是使用URL重定向到其他站点的资源

2.重定向访问过程后，浏览器的地址栏中显示的URL会发生改变，由初始的URL地址变成重定向的目标URL；请求转发结束后，浏览器地址栏的URL保持不变

3.重定向方法对浏览器的请求直接作出相应，相应的结果就是告诉浏览器去重新发出对另外一个URL的访问请求。

转发在服务器端内部将请求转发给另外一个资源，浏览器只知道发出了请求并得到了响应结果，并不知道在服务器程序内部发生了转发行为。

4.转发方法的调用者与被调用者之间共享相同的request对象和reponse对象，属于同一个访问请求和响应过程

重定向方法的调用者与被调用者使用各自的request对象和reponse对象，他们属于两个独立的访问请求和响应过程

5.无论是request.getRequestDispatcher().forward()方法，还是response.sendRedirect()方法，在调用它们之前，都不能有内容已经被实际输出到了客户端。如果缓冲区中已经有了一些内容，这些内容将被从缓冲区中。

1、转发使用的是getRequestDispatcher()方法;重定向使用的是sendRedirect();

2、转发：浏览器URL的地址栏不变。重定向：浏览器URL的地址栏改变；

3、转发是服务器行为，重定向是客户端行为；

4、转发是浏览器只做了一次访问请求。重定向是浏览器做了至少两次的访问请求

5、转发2次跳转之间传输的信息不会丢失，重定向2次跳转之间传输的信息会丢失（request范围）。

转发和重定向的选择
1、重定向的速度比转发慢，因为浏览器还得发出一个新的请求，如果在使用转发和重定向都无所谓的时候建议使用转发。

  **2、因为转发只能访问当前WEB的应用程序，所以不同WEB应用程序之间的访问，特别是要访问到另外一个WEB站点上的资源的情况，这个时候就只能使用重定向了。**

(一)计算机网络

一次请求的过程

域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户

七层协议模型？

1. 应用层
   • OSI参考模型中最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：HTTP，HTTPS，FTP，POP3、SMTP等。
   • 实际公司A的老板就是我们所述的用户，而他要发送的商业报价单，就是应用层提供的一种网络服务，当然，老板也可以选择其他服务，比如说，发一份商业合同，发一份询价单，等等。
2. 表示层
   • 表示层提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。如果必要，该层可提供一种标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和加密也是表示层可提供的转换功能之一。
   • 由于公司A和公司B是不同国家的公司，他们之间的商定统一用英语作为交流的语言，所以此时表示层（公司的文秘），就是将应用层的传递信息转翻译成英语。同时为了防止别的公司看到，公司A的人也会对这份报价单做一些加密的处理。这就是表示的作用，将应用层的数据转换翻译等。
3. 会话层
   • 会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。
   • 会话层的同事拿到表示层的同事转换后资料，（会话层的同事类似公司的外联部），会话层的同事那里可能会掌握本公司与其他好多公司的联系方式，这里公司就是实际传递过程中的实体。他们要管理本公司与外界好多公司的联系会话。当接收到表示层的数据后，会话层将会建立并记录本次会话，他首先要找到公司B的地址信息，然后将整份资料放进信封，并写上地址和联系方式。准备将资料寄出。等到确定公司B接收到此份报价单后，此次会话就算结束了，外联部的同事就会终止此次会话。
4. 传输层
   • 传输层建立了主机端到端的链接，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务，包括处理差错控制和流量控制等问题。该层向高层屏蔽了下层数据通信的细节，使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。我们通常说的，TCP UDP就是在这一层。端口号既是这里的“端”。
   • 传输层就相当于公司中的负责快递邮件收发的人，公司自己的投递员，他们负责将上一层的要寄出的资料投递到快递公司或邮局。
5. 网络层
   • 本层通过IP寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。就是通常说的IP层。这一层就是我们经常说的IP协议层。IP协议是Internet的基础。
   • 网络层就相当于快递公司庞大的快递网络，全国不同的集散中心，比如说，从深圳发往北京的顺丰快递（陆运为例啊，空运好像直接就飞到北京了），首先要到顺丰的深圳集散中心，从深圳集散中心再送到武汉集散中心，从武汉集散中心再寄到北京顺义集散中心。这个每个集散中心，就相当于网络中的一个IP节点。
6. 数据链路层
   • 将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用MAC地址)来访问介质,并进行差错检测。
   • 数据链路层又分为2个子层：逻辑链路控制子层（LLC）和媒体访问控制子层（MAC）。
   • MAC子层处理CSMA/CD算法、数据出错校验、成帧等；LLC子层定义了一些字段使上次协议能共享数据链路层。 在实际使用中，LLC子层并非必需的。
   • 这个没找到合适的例子
7. 物理层
   • 实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。规定了电平、速度和电缆针脚。常用设备有（各种物理设备）集线器、中继器、调制解调器、网线、双绞线、同轴电缆。这些都是物理层的传输介质。
   • 快递寄送过程中的交通工具，就相当于我们的物理层，例如汽车，火车，飞机，船。

• 通信特点：对等通信
• 对等通信，为了使数据分组从源传送到目的地，源端OSI模型的每一层都必须与目的端的对等层进行通信，这种通信方式称为对等层通信。在每一层通信过程中，使用本层自己协议进行通信。

每层有哪些协议？工作在这些层的设备

三次握手和四次挥手详细过程

• 客户端与服务器之间数据的发送和返回的过程当中需要创建一个叫TCP connection的东西；
• 由于TCP不存在连接的概念，只存在请求和响应，请求和响应都是数据包，它们之间都是经过由TCP创建的一个从客户端发起，服务器接收的类似连接的通道，这个连接可以一直保持，http请求是在这个连接的基础上发送的；
• 在一个TCP连接上是可以发送多个http请求的，不同的版本这个模式不一样。
  • 在HTTP/1.0中这个TCP连接是在http请求创建的时候同步创建的，http请求发送到服务器端，服务器端响应了之后，这个TCP连接就关闭了；
  • HTTP/1.1中可以以某种方式声明这个连接一直保持，一个请求传输完之后，另一个请求可以接着传输。这样的好处是：在创建一个TCP连接的过程中需要“三次握手”的消耗，“三次握手”代表有三次网络传输。
  • 如果TCP连接保持，第二个请求发送就没有这“三次握手”的消耗。HTTP/2中同一个TCP连接里还可以并发地传输http请求。

• 其中比较重要的字段有：

  1. 序号（sequence number）：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
  2. 确认号（acknowledgement number）：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
  3. 标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：
     • URG：紧急指针（urgent pointer）有效。
     • ACK：确认序号有效。
     • PSH：接收方应该尽快将这个报文交给应用层。
     • RST：重置连接。
     • SYN：发起一个新连接。
     • FIN：释放一个连接。
  • 不要将确认序号Ack与标志位中的ACK搞混了。确认方Ack=发起方Seq+1，两端配对。

三次握手

握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始“三次握手”：

1. 首先客户端向服务器端发送一段TCP报文，其中：
   • 标记位为SYN，表示“ 请求建立新连接 ”;
   • 序号为Seq=X（X一般为1）；
   • 随后客户端进入SYN-SENT阶段。
2. 服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，其中：
   • 标志位为SYN和ACK，表示“ 确认客户端的报文Seq序号有效 ，服务器能正常接收客户端发送的数据，并 同意创建新连接 ”（即告诉客户端，服务器收到了你的数据）；
   • 序号为Seq=y；
   • 确认号为Ack=x+1，表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值；随后服务器端进入SYN-RCVD阶段。
3. 客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。其中：
   • 标志位为ACK，表示“ 确认收到服务器端同意连接的信号 ”（即告诉服务器，我知道你收到我发的数据了）；
   • 序号为Seq=x+1，表示收到服务器端的确认号Ack，并将其值作为自己的序号值；
   • 确认号为Ack=y+1，表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值；
   • 随后客户端进入ESTABLISHED阶段。

• 服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。

• 在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失，便无法继续"握手"，以此确保了"三次握手"的顺利完成。

• 此后客户端和服务器端进行正常的数据传输。这就是“三次握手”的过程。
  

四次挥手

挥手之前主动释放连接的客户端结束ESTABLISHED阶段。随后开始“四次挥手”

1. 首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：

   • 标记位为FIN，表示“请求释放连接“；
   • 序号为Seq=U；
   • 随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。
   • 注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。

2. 服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：

   • 标记位为ACK，表示“接收到客户端发送的释放连接的请求”；
   • 序号为Seq=V；
   • 确认号为Ack=U+1，表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；
   • 随后服务器端开始准备释放服务器端到客户端方向上的连接。
   • 客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段

前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了

3. 服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：

   • 标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。
   • 序号为Seq=W；
   • 确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。
   • 随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。

4. 客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：

   • 标记位为ACK，表示“接收到服务器准备好释放连接的信号”。
   • 序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。
   • 确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。
   • 随后客户端开始在TIME-WAIT阶段等待2MSL

• 服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的连接。

• 客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。

• 与“三次挥手”一样，在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续"挥手"，以此确保了"四次挥手"的顺利完成。

为什么“握手”是三次

• “第三次握手”是客户端向服务器端发送数据，这个数据就是要告诉服务器，客户端有没有收到服务器“第二次握手”时传过去的数据。
• 如果只有两次握手，当网络错误，第二次握手的数据丢失时，服务器会重新发送。而客户端不知道，会重新建立连接，原来的端口就会一直打开等待。
• 三次是为了保证收到，若发送的这个数据是“收到了”的信息，接收后服务器就正常建立TCP连接，否则建立TCP连接失败，服务器关闭连接端口。
• 由此减少服务器开销和接收到失效请求发生的错误。

为什么“握手”是三次，“挥手”却要四次？

• 因为在第二次"握手"过程中，服务器端发送给客户端的TCP报文是以SYN与ACK作为标志位的。SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。即SYN建立连接报文与ACK确认接收报文是在同一次"握手"当中传输的

• TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。

• 建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。

• 释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

为什么客户端在TIME-WAIT阶段要等2MSL?

• 服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；
• 最差情况下需要1MSL的ACK传输时间+1MSL的FIN传输时间
• 如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；
• 否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。

---

(二)操作系统

常用服务及默认端口号

协议	解释	默认端口
http	超文本传输协议	80
https	http加密版	443
ftp	文件传输协议	20传输数据 21建立连接
stmp	简单邮件传输协议	25
ssh	linux远程连接端口	22
dns	域名解析服务器	53
MySQL	mysql数据库	3306
MongoDB	MongoDB数据库	27017
nacos	配置中心	8848
telnet	远程终端协议	23

TCP和UDP的区别

UDP协议和TCP协议都是传输层协议。

TCP（Transmission Control Protocol，传输控制协议）提供的是面向连接，可靠的字节流服务。即客户和服务器交换数据前，必须现在双方之间建立一个TCP连接，之后才能传输数据。并且提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。

UDP（User Data Protocol，用户数据报协议）是一个简单的面向数据报的运输层协议。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。由于UDP在传输数据报前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。