Stories with Tag network protocols

• You might not need WebSockets

  permalink

  Posted: 2025-04-11 22:27:16

  Verbose tl;dr

  The blog post "You might not need WebSockets" argues that developers often prematurely choose WebSockets for real-time features when simpler, more efficient solutions exist. It highlights server-sent events (SSE) as a robust alternative for unidirectional communication from server to client, offering benefits like automatic reconnection and built-in event handling. While acknowledging WebSockets' bi-directional capabilities, the post emphasizes that many use cases only require server-to-client updates, making SSE a lighter and potentially better-performing choice. It encourages developers to carefully analyze their needs before defaulting to WebSockets and consider the reduced complexity and improved resource utilization that SSE can provide.

  The blog post "You might not need WebSockets" argues that while WebSockets offer a persistent, bidirectional communication channel between client and server, they often introduce unnecessary complexity for many web applications. The author contends that simpler, more readily available technologies like HTTP long-polling and server-sent events (SSE) can adequately handle a significant portion of use cases where developers might instinctively reach for WebSockets.

  The core premise is that the perceived need for real-time, instantaneous updates is often a misunderstanding of actual user requirements. In many scenarios, near real-time updates—achieved with a slight delay—are perfectly acceptable and provide a comparable user experience without the overhead of managing WebSocket connections.

  The author elaborates on the challenges associated with WebSockets. These include increased complexity in both client and server implementations, difficulties with scaling due to the persistent nature of the connections, and the potential for increased latency in specific scenarios due to head-of-line blocking (though this can be mitigated). They contrast this with the relative simplicity of HTTP-based solutions.

  Server-Sent Events (SSE) are presented as a compelling alternative for scenarios where the server needs to push updates to the client. SSE leverages a standard HTTP connection, offering a lightweight solution for one-way communication. The author emphasizes the ease of implementation and inherent efficiency of SSE compared to WebSockets.

  Long-polling is discussed as another viable option, particularly when bidirectional communication is required. While acknowledging the limitations of long-polling, such as the potential for increased latency and resource consumption compared to WebSockets under high-load conditions, the author argues that its simplicity can outweigh these drawbacks in less demanding applications. It's presented as a useful stepping stone before resorting to the complexity of WebSockets.

  The article further delves into specific scenarios and provides practical guidance on choosing the appropriate technology. It encourages developers to carefully consider their actual needs and evaluate whether the benefits of WebSockets truly outweigh the costs. The author concludes by recommending a tiered approach, starting with simpler solutions like SSE or long-polling and only escalating to WebSockets when absolutely necessary, emphasizing that premature optimization is often counterproductive. They advocate for choosing the simplest tool that effectively addresses the problem at hand.

  • WebSockets
  • HTTP
  • Server-Sent Events
  • SSE
  • Real-time
  • Web Development
  • performance
  • Alternatives to WebSockets
  • Polling
  • long polling
  • complexity
  • Over-engineering
  • network protocols

  Summary of Comments ( 228 )
  https://news.ycombinator.com/item?id=43659370

  Verbose tl;dr

  HN commenters largely agree with the author's premise that WebSockets are often overused for real-time updates when simpler solutions like HTTP long-polling or Server-Sent Events (SSE) would suffice. Several pointed out the added complexity of WebSockets, both in implementation and infrastructure, with one commenter noting the difficulty in scaling WebSocket connections. The benefits of SSE, particularly its simplicity and native browser support, were highlighted. Some suggested that the choice depends heavily on the specific use case, with WebSockets being more suitable for highly interactive applications like online games, while others argued that even these could be served efficiently with alternatives. A few commenters mentioned the advantages of WebSockets in terms of lower latency and bi-directional communication, but these were generally seen as niche benefits that don't justify the added complexity for most applications. The general consensus seemed to be: consider simpler options first, and only reach for WebSockets when absolutely necessary.

  The Hacker News post "You might not need WebSockets" (https://news.ycombinator.com/item?id=43659370) sparked a discussion with several insightful comments. Many commenters agreed with the author's premise that WebSockets are often overused for real-time updates when simpler solutions like HTTP long-polling or Server-Sent Events (SSE) would suffice.

  One compelling argument highlighted the added complexity introduced by WebSockets, including connection management, reconnection logic, and handling various edge cases. Commenters pointed out that this complexity can lead to increased development time and potentially more bugs, especially for smaller projects or less experienced developers. They argued that unless bidirectional communication is absolutely necessary, the simpler alternatives are preferable.

  Several users shared their personal experiences where they successfully replaced WebSockets with SSE or long-polling, resulting in improved performance and simplified codebases. They emphasized the importance of evaluating the actual requirements before opting for WebSockets.

  The discussion also touched upon the performance aspects of each approach. While some argued that WebSockets offer lower latency, others contended that the difference is negligible for many applications, and the overhead introduced by WebSockets can sometimes negate its theoretical advantages. The point was made that the latency introduced by network conditions often dwarfs the differences between these technologies.

  Another key takeaway from the comments is the importance of considering the specific use case. For chat applications or highly interactive games, WebSockets might be the best choice. However, for applications that primarily involve server-pushed updates, like stock tickers or notification systems, SSE or long-polling are often more suitable.

  A few commenters mentioned the better browser compatibility of SSE and long-polling compared to WebSockets, although this is less of a concern in modern web development.

  Overall, the comments on the Hacker News post generally supported the article's claim that WebSockets are often unnecessarily complex and that simpler alternatives should be considered first. The discussion provided practical advice and real-world examples to help developers make informed decisions about the best technology for their real-time applications.

• What would happen if we didn't use TCP or UDP?

  permalink

  Posted: 2025-02-25 07:13:23

  Verbose tl;dr

  Without TCP or UDP, internet communication as we know it would cease to function. Applications wouldn't have standardized ways to send and receive data over IP. We'd lose reliability (guaranteed delivery, in-order packets) provided by TCP, and the speed and simplicity offered by UDP. Developers would have to implement custom protocols for each application, leading to immense complexity, incompatibility, and a much less efficient and robust internet. Essentially, we'd regress to a pre-internet state for networked applications, with ad-hoc solutions and significantly reduced interoperability.

  The hypothetical scenario of a world without TCP or UDP, the two dominant transport layer protocols of the internet protocol suite, would drastically reshape how networked communication functions. The post explores the potential consequences and alternatives, emphasizing the crucial role these protocols play in ensuring reliable and efficient data transmission.

  Without TCP and UDP, the fundamental mechanisms for establishing connections, managing data flow, and ensuring data integrity would be absent. Applications relying on these features would cease to function as intended. This includes the vast majority of internet services we use daily: web browsing (HTTP/HTTPS), email (SMTP), file transfer (FTP), and real-time communication (VoIP, video streaming). These services depend on the guarantees provided by TCP and UDP, whether it be the ordered, reliable delivery of TCP or the connectionless, speed-prioritizing nature of UDP. Their absence would necessitate entirely new protocols or radical adaptations to existing application-layer protocols.

  The post outlines potential alternatives, including the possibility of applications implementing their own custom transport layer functionalities. This implies each application would need to handle tasks like segmentation, reassembly, error detection, and flow control individually. This approach would lead to significant redundancy, increased complexity in application development, and potential inconsistencies in how data is handled across different applications. It also raises concerns about interoperability, as applications using different custom transport mechanisms might struggle to communicate effectively.

  Furthermore, the post highlights the potential for operating systems to absorb some of the responsibilities currently handled by TCP and UDP. This could involve the OS providing basic segmentation and reassembly services or offering a simplified, generalized transport mechanism for applications to utilize. However, this approach also introduces complexities in OS design and could potentially impact performance.

  Ultimately, a world without TCP or UDP would likely see a more fragmented and less efficient internet. The standardized, universally adopted nature of these protocols is a key contributor to the internet's success. Their removal would necessitate significant re-engineering of the entire networking landscape and potentially hinder the seamless communication we currently take for granted. The post leaves open the possibility of novel solutions emerging, but emphasizes the immense challenge of replicating the functionality and widespread adoption of these essential protocols.

  • networking
  • protocols
  • TCP
  • UDP
  • Internet
  • Communication
  • low-level networking
  • Computer Science
  • network protocols
  • data transfer
  • ip
  • network stack
  • osi model
  • alternatives to tcp/udp
  • network fundamentals

  Summary of Comments ( 60 )
  https://news.ycombinator.com/item?id=43169103

  Verbose tl;dr

  Hacker News users discussed alternatives to TCP/UDP and the implications of not using them. Some highlighted the potential of QUIC and HTTP/3 as successors, emphasizing their improved performance and reliability features. Others explored lower-level protocols like SCTP as a possible replacement, noting its multi-streaming capabilities and potential for specific applications. A few commenters pointed out that TCP/UDP abstraction is already somewhat eroded in certain contexts like RDMA, where applications can interact more directly with the network hardware. The practicality of replacing such fundamental protocols was questioned, with some suggesting it would be a massive undertaking with limited benefits for most use cases. The discussion also touched upon the roles of the network layer and the possibility of protocols built directly on IP, acknowledging potential issues with fragmentation and reliability.

  The Hacker News post titled "What would happen if we didn't use TCP or UDP?" sparked a discussion with several interesting comments exploring alternatives and the fundamental roles of TCP and UDP.

  One commenter highlighted the existence of other protocols like QUIC and SCTP, suggesting that the question isn't entirely hypothetical, as the internet is already exploring alternatives. They mentioned that QUIC, in particular, is gaining traction. Another commenter pointed out that HTTP/3 uses QUIC, further emphasizing the shift away from exclusive reliance on TCP and UDP.

  Delving deeper into the theoretical aspects, a user explained that IP itself doesn't mandate TCP or UDP. They described how the IP protocol provides a "best-effort" delivery mechanism, and TCP/UDP build upon it to offer features like reliability (TCP) and connectionlessness (UDP). They further explained that one could theoretically implement other protocols on top of IP.

  Another comment emphasized the importance of some protocol for managing port numbers and multiplexing applications. They argued that even if TCP/UDP weren't used, a similar system would be needed to handle these functionalities. This highlighted the core problem that TCP/UDP solve, which is not inherently tied to their specific implementations.

  One commenter humorously suggested ICMP as an alternative, acknowledging its impracticality but emphasizing the theoretical possibility of building something upon it. This highlighted the point that IP itself is the foundational layer, and other protocols are built on top.

  Expanding on the core functionalities, another comment explained that flow control and congestion control are not inherent to IP and are managed by higher-level protocols. They explained that without mechanisms like those provided by TCP, the network would quickly become congested and unusable.

  Another commenter proposed a thought experiment of removing only UDP, highlighting the reliance of DNS and other services on UDP and the disruptive consequences of such a change. This highlighted the specific niche filled by UDP and its importance to the current internet infrastructure.

  Finally, some comments discussed the historical context of TCP and UDP, mentioning pre-IP protocols like IPX/SPX, and how these offered similar functionalities. This offered a perspective on how the current internet architecture evolved and that the core concepts predate TCP/UDP.

  In summary, the comments on the Hacker News post explored various facets of the question, from existing alternatives and their adoption, to the fundamental roles of TCP/UDP in managing ports, multiplexing applications, and providing crucial functionalities like flow control and congestion control. The discussion also touched upon the theoretical possibility of designing entirely new protocols on top of IP and considered the practical implications of removing either UDP or TCP.