程序员的自我修养

发表于 更新于 分类于

JavaScript执行顺序

JavaScript(以下简称js) 是一种描述型脚本语言，由浏览器进行动态的解析与执行。由于js编写位置比较灵活，所以处在不同位置的js代码执行顺序也是不同的。js和其他编程语言相比比较随意，所以js代码中充满各种奇葩的写法。苦逼的公司造就苦逼程序员全栈工程师，工作中总是经常自己写些简单的前端页面，经常被js的执行顺序袭扰，索性找个大块儿时间好好学习总结下，理解各型各色的写法，希望能对js的语言特性有深入的理解。

函数的声明和调用

函数的定义方式大体有以下两种，浏览器对于不同的方式有不同的解析顺序。

  1. 使用function关键字声明一个函数，再指定一个函数名，叫函数声明。
    1
    2
    3
    function Fn1(){ 
        alert("Hello World!"); 
    }
  2. 使用function关键字声明一个函数，但未给函数命名，最后将匿名函数赋予一个变量，叫函数表达式，这是最常见的函数表达式语法形式。
    1
    2
    3
    var Fn2 = function(){ 
        alert("Hello World!"); 
    }
    如果遇到函数声明，则进行预处理(类似C语言的编译)；如果遇到函数表达式，则只是将函数赋值给一个变量，不进行预处理，待调用的时候再进行处理。
    @(#函数声明)
    1
    2
    3
    4
    Fn1();
    function Fn1(){
        alert("Hello World!");
    }
    👆↑ 这段代码()可以正常运行，弹出”Hello World!”警告对话框。浏览器对Fn1()进行了预处理，再从Fn1()；开始运行。
阅读全文 »

发表于 更新于 分类于

TCP重传机制

TCP要保证所有的数据包都可以到达，所以，必需要有重传机制。

注意，接收端给发送端的ACK只会确认最后一个连续的包。比如，发送端发了#1,#2,#3,#4,#5一共五份数据，接收端收到了#1，#2，于是返回ACK=3，然后收到了#4（#3未收到），此时的TCP会怎么办？我们要知道，seq和ACK是以字节数为单位，所以返回ack的时候，不能跳着确认，只能确认最大的连续收到的包，不然，发送端就以为之前的都收到了。

超时重传机制

一种是不返回ack，死等#3，当发送方发现收不到#3的ack超时后，会重传#3。一旦接收方收到#3后，会ack返回4——意味着#3和#4都收到了。

阅读全文 »

发表于 更新于 分类于

TCP 连接的建立与释放

TCP 是面向连接的，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。在TCP/IP协议中，TCP协议提供可靠的连接服务，连接是通过三次握手进行初始化的。

TCP 连接的三个阶段：

  1. 连接建立。
  2. 数据传送。
  3. 连接释放。

TCP 连接建立过程中要解决的问题：

阅读全文 »

发表于 更新于 分类于

关于TCP

TCP 简介

TCP协议具体是什么，不赘述，百度之。

我们经常听人说 TCP 是一个面向连接的(connection-oriented)、可靠的(reliable)、字节流式(byte stream)传输协议，TCP 的这三个特性该怎么理解呢？

  • 面向连接：在应用 TCP 协议进行通信之前双方通常需要通过三次握手来建立 TCP 连接，连接建立后才能进行正常的数据传输，因此广播和多播不会承载在 TCP 协议上。(谷歌提交了一个 RFC 文档，建议在 TCP 三次握手的过程允许 SYN 数据包中带数据，即 TFO(TCP Fast Open)，目前 ubuntu 14.04已经支持该 TFO 功能)。但是同时面向连接的特性给 TCP 带来了复杂的连接管理以及用于检测连接状态的存活检测机制。

  • 可靠性：由于 TCP 处于多跳通信的 IP 层之上，而 IP 层并不提供可靠的传输，因此在TCP层看来就有四种常见传输错误问题，分别是比特错误(packet bit errors)、包乱序(packet reordering)、包重复(packet duplication)、丢包(packet erasure或称为packet drops)，TCP 要提可靠的传输，就需要有额外的机制处理这几种错误。因此可靠性体现在三个方面：

    1. TCP 通过超时重传和快速重传两个常见手段来保证数据包的正确传输，也就是说接收端在没有收到数据包或者收到错误的数据包的时候会触发发送端的数据包重传(处理比特错误和丢包)。
    2. **TCP 接收端会缓存接收到的乱序到达数据，重新排序后再向应用层提供有序的数据(处理包乱序)**。
    3. **TCP 发送端会维持一个发送『窗口』动态的调整发送速率以适用接收端缓存限制和网络拥塞情况，避免了网络拥塞或者接收端缓存满而大量丢包的问题(降低丢包率)**。
      因此可靠性需要 TCP 协议具有超时与重传管理、窗口管理、流量控制、拥塞控制等功能。另外 TFO 下 TCP 有可能向应用层提供重复的数据，也就是不可靠传输，但是只会发生在连接建立阶段。

  • 字节流式：应用层发送的数据会在 TCP 的发送端缓存起来，统一分片(例如一个应用层的数据包分成两个 TCP 包)或者打包(例如两个或者多个应用层的数据包打包成一个 TCP 数据包)发送，到接收端的时候接收端也是直接按照字节流将数据传递给应用层。作为对比，同样是传输层的协议，UDP 并不会对应用层的数据包进行打包和分片的操作，一般一个应用层的数据包就对应一个 UDP 包。这个也是伴随 TCP 窗口管理、拥塞控制等。

阅读全文 »

发表于 更新于 分类于

国庆休息8天，赋闲在家，也只有在老家的时候可以做到晚上八点上床睡觉。。
闲来无事，不记得之前在哪里看到的hexo博客搭建。昨天下午小事了一下，成就感满满。中途遇到访问本站总是跳转到 https://someiscoding.com ，但自己明明没有购买域名，导致每次DNS服务器无法解析地址。后来索性把GitHub上的账户名修改了下，重新配置了下_config文件，终于可以正常访问了。紧接着就是更换主题，选取比较稳妥的next主题，网上关于配置next的教程比较多，上手还快一些~因为中间一直使用终端，用的又是mac，不知道什么原因，终端中连ls命令都无法使用，总是提示命令无法找到什么的，一直以为是权限不够，需要开始ROOT权限。后来发现切换到bash中可以正常执行，默认启动的zsh不行。网上查了下，有的说是.zshrc文件中配置有问题，可能是PATH环境变量没有包括各种bin&sbin。于是，在终端echo $PATH发现有bin和sbin。折腾了两个小时，还是误解，，罢了，索性备份了.zshrc文件，重新安装了oh-my-zsh。
嗯，，完美！高兴！

记第一篇流水账。

发表于 更新于 分类于

hello world!
from Shang.

0%