
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Sun, 26 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/server-sent-events/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/architecture/2026-07-26-websocket-vs-sse-vs-polling</guid>
    <title>웹소켓, SSE, 폴링 — 실시간 통신 방식 고르기와 대부분 웹소켓이 필요 없는 이유</title>
    <link>https://www.youngju.dev/blog/architecture/2026-07-26-websocket-vs-sse-vs-polling</link>
    <description>실시간이라는 요구사항 대부분은 서버에서 클라이언트로 가는 단방향 전달이고, 그런 경우 SSE가 웹소켓보다 훨씬 단순하면서 HTTP 인프라를 그대로 씁니다. 자동 재연결과 Last-Event-ID 재개가 규격에 내장되어 있고 인증과 로깅과 압축이 평소 쓰던 것과 같습니다. 폴링과 롱폴링을 포함한 네 방식의 지연과 비용을 표로 비교하고, 웹소켓이 정말 필요한 경계를 정합니다. 프록시 유휴 타임아웃과 버퍼링, HTTP/1.1의 커넥션 한도, 수평 확장 시 필요한 펍섭, 하트비트와 백프레셔 설계, 그리고 동시 연결 수에 따른 메모리 계산까지 실제 운영에서 부딪히는 것들을 정리했습니다.</description>
    <pubDate>Sun, 26 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>web</category><category>websocket</category><category>server-sent-events</category><category>realtime</category><category>scalability</category>
  </item>

    </channel>
  </rss>
