What's the main difference between bidirectional and directional sockets?

只愿长相守 提交于 2019-12-01 05:47:29
Remy Lebeau

Bidirectional means data flows in both directions, whereas Unidirectional means data flows in only one direction. A socket is created as a bidirectional resource (capable of both sending and receiving), even if it is only used in a unidirectional manner in code. You can optionally use shutdown() to close one direction of data flow if you are not going to use it (ie, shutdown(SD_SEND) on a receive-only socket, or shutdown(SD_RECEIVE) on a send-only socket).

A WebSocket is still a socket, just one that runs in a web browser, and whose transmitted data has to be framed in a particular format according to the WebSocket spec. A WebSocket can send/receive arbitrary data, just like an ordinary socket can, it just has to have the data wrapped in frames that need to be decoded on the receiving end.

bind(), whether called on the client side or the server side (yes, it can be called on both), tells the OS which local IP/Port pair to associate with the socket before the connection is established. A socket is uniquely identified by its socket protocol type (UDP, TCP, etc), its local bound IP/Port pair, and its connected remote IP/Port pair. Network packets that do not match an established socket connection are discarded.

On the client side, calling bind() is optional, as connect() will bind implicitly if bind() has not been called. bind() is useful if the client has multiple network adapters installed and wants to specify which one to connect out with, or if the client must use a specific local port (dictated by data protocol, firewall rules, etc).

On the server side, bind() is required, to establish the IP/Port that the server listens on to accept clients on.

Websockets are an attempt to work around the pull model of http, e.g. where the client does a http query and the server does a http response and that's the end of the talk. But often more than that is needed, e.g. server push or just classical bidirectional communication not limited to request+response. In a world without firewalls one would use classical sockets for this task, but in todays world lots of communication is restricted and direct connections to arbitrary ports will not work any more.

Websockets work around this problem be upgrading an established HTTP communication. E.g. the client requests an HTTP upgrade, and if they server agrees both can talk from now on inside this HTTP connection like they would do with a simple TCP connection. In reality they have some framing and data mangling inside, but this detail is hidden from the user. In a way it is similar to the CONNECT method used by browsers to establish an (https) tunnel through a web proxy.

Of course this means, that a Websocket connection can only be established between a web client supporting the protocol (most recent browsers do) and a web server implementing Websockets. This especially means, that you cannot use Websockets to connect to UDP sockets or to arbitrary TCP sockets (unless the web server forwards these data). But this also means, that if you use upgrade an https connection to Websockets the Websockets connection will be transparently SSL protected too. But, even if client and server are supporting Websockets the connection upgrade might fail, if there is a web proxy in between which does not understand Websockets or will explicitly block them.

In case you understand german https://blog.genua.de/blog/post/loecher-in-der-firewall-mit-websockets.html might give you an interesting read about how Websockets fit in the network stack and about their security implications.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!