You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CS/Network/socket.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -43,7 +43,7 @@ rest API를 사용하면 위 사진과 같은 방식으로 통신을 하게된
43
43
- short polling
44
44
- long polling
45
45
46
-
short polling은 메리의 앱이나 존의 앱이 get 방식을 통해서 새로운 메시지가 이쓴ㄴ지 짧은 시간 텀(타이머)을 가지고 확인하는 방식이다. 계속 반복하다 보면 메시지가 새로 수신되면 메리의 앱에서는 message end-point로부터 업데이트된 셋을 db로 부터 요청하게 된다. 사람들은 이런 쉬운 방법의 의존성 때문에 이용하지만 이 방식은 server, client 모두에게 좋지 않은 방식이다. 왜냐하면 latency delay가 발생하기 때문이다. 만약 타이머를 5초를 두면 5초 간격마다 메시지 딜레이가 발생하게 된다. 그리고 http로 통신하기 때문에 request가 발생할 때마다 server로 요청하게 되는데 이 때문에 서버에 부하가 발생한다.
46
+
short polling은 메리의 앱이나 존의 앱이 get 방식을 통해서 새로운 메시지가 있는지 짧은 시간 텀(타이머)을 가지고 확인하는 방식이다. 계속 반복하다 보면 메시지가 새로 수신되면 메리의 앱에서는 message end-point로부터 업데이트된 셋을 db로 부터 요청하게 된다. 사람들은 이런 쉬운 방법의 의존성 때문에 이용하지만 이 방식은 server, client 모두에게 좋지 않은 방식이다. 왜냐하면 latency delay가 발생하기 때문이다. 만약 타이머를 5초를 두면 5초 간격마다 메시지 딜레이가 발생하게 된다. 그리고 http로 통신하기 때문에 request가 발생할 때마다 server로 요청하게 되는데 이 때문에 서버에 부하가 발생한다.
47
47
48
48
이를 개선한 방법으로 long polling이 있다. long polling을 이용하게 되면 매 x초마다 검사를 하는 것이 아니고 delay를 줘서 만약 새로운 메시지가 수신될 때마다 request를 하는 방식이다. short polling에 비해서 좋은 방식이지만 적용시키기에 다소 어렵고 백엔드에서 더 많은 작업이 요구된다.
0 commit comments