，是指使用字节流传输数据，说白了就是TCP协议。

如果传入的是SOCK_DGRAM，是指使用数据报传输数据，也就是UDP协议。

返回的fd是指socket句柄，可以理解为socket的身份证号。通过这个fd你可以在内核中找到唯一的socket结构。

如果想要通过这个socket发消息，只需要操作这个fd就行了，比如执行 send(fd, msg, ...)，内核就会通过这个fd句柄找到socket然后进行发数据的操作。

如果一切顺利，此时对方执行接收消息的操作，也就是 recv(fd, msg, ...)，就能拿到你发的消息。

对于异常情况的处理

但如果不顺利呢？

比如消息发到一半，丢包了呢?

丢包的原因有很多，之前写过的《用了TCP协议，就一定不会丢包吗？》有详细聊到过，这里就不再展开。

那UDP和TCP的态度就不太一样了。

UDP表示，"哦，是吗？然后呢？关我x事"

TCP态度就截然相反了，"啊？那可不行，是不是我发太快了呢？是不是链路太堵被别人影响到了呢？不过你放心，我肯定给你补发"

TCP老实人石锤了。我们来看下这个老实人在背后都默默做了哪些事情。

重传机制

对于TCP，它会给发出的消息打上一个编号（sequence），接收方收到后回一个确认(ack)。发送方可以通过ack的数值知道接收方收到了哪些sequence的包。

如果长时间等不到对方的确认，TCP就会重新发一次消息，这就是所谓的重传机制。

流量控制机制

但重传这件事本身对性能影响是比较严重的，所以是下下策。

于是TCP就需要思考有没有办法可以尽量避免重传。

因为数据发送方和接收方处理数据能力可能不同，因此如果可以根据双方的能力去调整发送的数据量就好了，于是就有了发送和接收窗口，基本上从名字就能看出它的作用，比如接收窗口的大小就是指，接收方当前能接收的数据量大小，发送窗口的大小就指发送方当前能发的数据量大小。TCP根据窗口的大小去控制自己发送的数据量，这样就能大大减少丢包的概率。

滑动窗口机制

接收方的接收到数据之后，会不断处理，处理能力也不是一成不变的，有时候处理的快些，那就可以收多点数据，处理的慢点那就希望对方能少发点数据。毕竟发多了就有可能处理不过来导致丢包，丢包会导致重传，这可是下下策。因此我们需要动态的去调节这个接收窗口的大小，于是就有了滑动窗口机制。

看到这里大家可能就有点迷了，