发表于 | 更新于:

DNS服务器之顺藤摸瓜

拿 www.google.com.来举例。其实可以类比为找朋友。

  1. 首先本机通过自己设置的最近的DNS服务器去找寻根域名，本机问道根域名服务器，你认不认识www.google.com,跟服务器答道我不认识，但是我认识com域名服务器.
  2. 同理，问com域名服务器，你是否认识www.google,com域名解析器答道，我认识存放google的域名解析器.

第一章和第二章的总结

注意，双引号内的部分即还不确定的部分，待完善

  • 解析域名：从第一章节的浏览器解析url开始，浏览器将输入的url交由DNS服务器解析域名，拿到域名背后的ip地址。
  • 与服务器建立通信：分为connection,write,read,close四个阶段，建立通信的过程需要三次握手，以及通过查找服务器的对应端口号建立套接字。建立好了通信之后就可以进行下一个阶段-发数据包了。住：建立通信的阶段也在发包，只不过主要有IP头部，MAC头部等，但是发的包中没有数据。其实发包的种类也有很多，ACK包等。
  • 生成包，发包过程中各个硬件的相互协调：涉及到的软硬件有网卡，网卡驱动，协议栈。其中协议栈可以认为是操作系统的一个部分，它掌管着TCP/IP/UDP，发送的数据包需要经过他所掌管的这几个协议进行加工，也就是给数据包加入头部信息（数据信息、控制信息）。网卡有ROM，MAC，ROM中存放着网卡出场时设置的全世界唯一的MAC地址，MAC作为一种控制层。
  • 协议栈中的TCP/IP：IP只管发送包，IP头部信息含有接送方的IP地址。

    第一章和第二章中待回顾的问题

  1. 表示网络包收件人的接收方IP地址是位于IP头部还是TCP头部？
  2. 端口号用来指定服务器程序的种类，他是位于TCP头部还是IP头部？
  3. 会对包是否正确送达进行确认的时TCP还是IP？
  4. 根据IP地址查询MAC地址的机制叫什么？
  5. 在收到ACK号之前继续发送下一个包的方式叫什么?

  6. 协议栈与操作系统的关系？以及协议栈与TCP/IP/UDP的关系?

  7. 表示网络包收件人的接收方IP地址位于IP头部，但是该信息并不是由IP产生，而是由应用程序生成，然后，应用程序交给TCP层，再由TCP层交给IP层，IP层再给数据包封装头部。

  8. TCP头部
  9. 书2.3.3
  10. ARP机制，拿一个子网来说，发送方在查询MAC地址时，首先通过广播的方式，向子网内的所有设备问：“谁的ip地址是xxxxx”,符合条件的设备答道:”我的ip地址符合，我的mac地址是xxxx”,不符合条件的设备即使收到了该条信息也不做回复。
  11. 滑动窗口方式，该方式是指接收方在没有收到发送方返回的ACK包之前，继续发送下一个数据包，这样可以提升通信的效率，但是发送两个数据包之间的间隔需要按规则来设定，不能过大也不能过小。

自主探索ip

  1. 当启用了代理服务器的时候去访问url，remote adrress:127.0.0.1：1080 代表的是本地代理端口，也就是本机从代理服务器获取数据的端口。
  2. 若不启用代理服务器，那么客户端会去访问真实的url
  3. 无论是否使用了代理服务器，浏览器在加载一次页面之后，会将部分数据存入内存缓存，下次访问的时候会从内存中获取。

发表于 | 更新于:

原文链接

在F12中的console模式下看CORS

  • 后端springboot代码

    1
    2
    3
    4
    5
    6
    7
    8
    9
     @PostMapping("greet/{name}")
        public String delete(@PathVariable("name") String name) {
            return "hello"+name;
        }

    @GetMapping({"greet","/"})
        public String delete(){
            return "hello";
        }

  • Console中代码 

    1
    2
    3
    4
    5
    6
    7
    fetch(
      'http://localhost:8080/greet/yawen',
      {
        method: 'POST',
        headers: { 'Content-Type': 'text/plain' },
      }
    ).then(resp => resp.text()).then(console.log)

    图片1
    图片2

preflight request

图片3
图片4

跨域请求中，浏览器会发出两个请求，一个是OPTION请求，另一个是POST请求。在OPTIONS请求中，状态码为200，但是请求依然不成功（报红)说明，浏览器没有拦截request请求，拦截的是response响应。

这是浏览器的预检请求

浏览器会对CORS认为复杂的请求执行预检请求，有如下标准:

  1. 除了GET,POST,HEAD方法
  2. 除了headers中的Accept,Accept-Language,Content-Language
  3. 除了Content-Type: text/plain,multipart/form-data (application/json会执行OPTION预检)

如何避免预检

  1. 1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    fetch(
      'http://localhost:4000/greet',
      {
        method: 'POST',
        headers: {
          'Content-Type': 'text/plain'
        },
        body: 'Ilija'
      }
    )
    .then(resp => resp.text())
    .then(console.log)
    此方法可以不执行预检，但是依然避免不了post请求.通过如下操作可以继续避免post请求，从而实现跨域请求.
1
2
3
4
5
6
7
8
options "/greet" do |env|
  # Allow `POST /greet`...
  env.response.headers["Access-Control-Allow-Methods"] = "POST"
  # ...with `Content-type` header in the request...
  env.response.headers["Access-Control-Allow-Headers"] = "Content-type"
  # ...from https://www.google.com origin.
  env.response.headers["Access-Control-Allow-Origin"] = "https://www.google.com"
end

Best Practice

仅仅只允许yourwebsite.com发送request

图片
图片
在某些情况下，需要对网站进行分析，这时，就需要浏览器发送有关用户在该网站上的体验的数据给后台，但是，却又不希望所有的站点都能够通过该后台的API来发送无关的数据，此时，后台中的代码,Access-Control-Allow-Origin:yourwebsite.com，通过该设置就可以只获取该网站发送来的数据了.