[롱 폴링] 상단 번역

Author: Violet-Bora-Lee

5-network/10-long-polling/article.md

@@ -1,71 +1,71 @@
-# Long polling
+# 롱 폴링
 
-Long polling is the simplest way of having persistent connection with server, that doesn't use any specific protocol like WebSocket or Server Side Events.
+롱 폴링(long polling)을 사용하면 웹소켓이나 server-sent event 같은 특정한 프로토콜을 사용하지 않아도 아주 간단히 서버와 지속적인 커넥션을 유지할 수 있습니다.
 
-Being very easy to implement, it's also good enough in a lot of cases.
+롱 폴링은 구현이 매우 쉽고 다양한 경우에 사용할 수 있습니다.
 
-## Regular Polling
+## 폴링
 
-The simplest way to get new information from the server is periodic polling. That is, regular requests to the server: "Hello, I'm here, do you have any information for me?". For example, once every 10 seconds.
+폴링(regular polling)을 사용하면 서버에서 새로운 정보를 아주 간단히 받을 수 있습니다. 10초에 한 번씩 서버에 "안녕하세요. 저 클라이언트인데 새로운 정보 줄거 있나요?" 라고 요청을 보내는 식으로 말이죠.
 
 In response, the server first takes a notice to itself that the client is online, and second - sends a packet of messages it got till that moment.
 
-That works, but there are downsides:
-1. Messages are passed with a delay up to 10 seconds (between requests).
-2. Even if there are no messages, the server is bombed with requests every 10 seconds, even if the user switched somewhere else or is asleep. That's quite a load to handle, speaking performance-wise.
+폴링은 지속적인 커넥션 유지라는 목적을 달성시켜 주지만 몇 가지 단점이 있습니다.
+1. 메시지 전달이 지연(예: 요청 주기가 10초인 경우엔 10초)됩니다.
+2. 전달할 메시지가 없는 경우에도 서버는 일정 주기마다(예: 10초마다) 요청 폭탄을 받습니다. 사용자가 다른 곳으로 전환했거나 중지 상태(sleep mode)라도 마찬가지입니다. 성능 면에서 불리합니다.
 
-So, if we're talking about a very small service, the approach may be viable, but generally, it needs an improvement.
+서비스 규모가 작은 경우 폴링은 꽤 괜찮은 방식입니다. 하지만 일반적인 경우엔 개선이 필요합니다.
 
-## Long polling
+## 롱 폴링
 
-So-called "long polling" is a much better way to poll the server.
+롱 폴링(long polling)은 일반 폴링보단 더 나은 방식입니다.
 
-It's also very easy to implement, and delivers messages without delays.
+롱 폴링은 폴링과 마찬가지로 구현이 쉬운데, 지연 없이 메시지를 전달한다는 차이가 있습니다.
 
-The flow:
+롱 폴링은 다음 절차로 이뤄집니다.
 
-1. A request is sent to the server.
-2. The server doesn't close the connection until it has a message to send.
-3. When a message appears - the server responds to the request with it.
-4. The browser makes a new request immediately.
+1. 서버에 요청이 전달됩니다.
+2. 서버는 전송할 메시지를 확보하기 전까지(이벤트 발생 전까지) 커넥션을 끊지 않고 유지합니다.
+3. 전송할 메시지를 확보하면(이벤트가 발생하면) 서버는 이 메시지를 가지고 요청에 대해 응답합니다.
+4. 브라우저는 응답을 받자마자 또 다른 새 요청을 보냅니다.
 
-The situation when the browser sent a request and has a pending connection with the server, is standard for this method. Only when a message is delivered, the connection is reestablished.
+롱 폴링은 브라우저가 요청을 보내고 서버와의 커넥션이 대기 중인 경우 표준으로 사용되는 방식입니다. 서버에서 클라이언트로 메시지가 전달된 후에만 커넥션이 다시 생성됩니다.
 
 ![](long-polling.svg)
 
-If the connection is lost, because of, say, a network error, the browser immediately sends a new request.
+롱 폴링 방식에선 네트워크 에러 등으로 커넥션이 유실되면 브라우저가 즉시 새로운 요청을 보냅니다.
 
-A sketch of client-side `subscribe` function that makes long requests:
+다음과 같은 클라이언트 측 구독(`subscribe`) 함수는 롱 요청을 가능하게 해줍니다.
 
 ```js
 async function subscribe() {
   let response = await fetch("/subscribe");
 
   if (response.status == 502) {
-    // Status 502 is a connection timeout error,
-    // may happen when the connection was pending for too long,
-    // and the remote server or a proxy closed it
-    // let's reconnect
+    // 502 상태코드는 커넥션 타임아웃 에러(connection timeout error)를 나타내는데,
+    // 커넥션 대기 시간이 너무 길거나
+    // 리모트 서버 혹은 프록시 서버가 커넥션을 종료한 경우 발생합니다.
+    // 재연결을 시도합니다.
     await subscribe();
   } else if (response.status != 200) {
-    // An error - let's show it
+    // 에러가 발생하면 에러 관련한 메시지를 보여줍니다.
     showMessage(response.statusText);
-    // Reconnect in one second
+    // 1초 후 재연결을 시도합니다.
     await new Promise(resolve => setTimeout(resolve, 1000));
     await subscribe();
   } else {
-    // Get and show the message
+    // 응답받은 메시지를 보여줍니다.
     let message = await response.text();
     showMessage(message);
-    // Call subscribe() again to get the next message
+    // 다음 메시지를 받기 위해 다시 subscribe()를 호출합니다.
     await subscribe();
   }
 }
 
 subscribe();
 ```
 
-As you can see, `subscribe` function makes a fetch, then waits for the response, handles it and calls itself again.
+롱 폴링을 구현한 함수 `subscribe`는 보시다시피 fetch를 사용해 요청을 보내고 응답이 올 때까지 기다린다음 응답을 처리하고 스스로 다시 요청을 보냅니다.
 
 ```warn header="Server should be ok with many pending connections"
 The server architecture must be able to work with many pending connections.