본문 바로가기

Basic/네트워크

폴링 롱폴링 웹소켓

반응형


폴링

단점은 폴링은 요청이 수없이 들어가는것




롱폴링


롱폴링의 단점

롱폴링은 바로 이러한 폴링의 한계를 보완할 수 있는 기법으로 이 기술을 서버 푸쉬라고 부르기도 한다.

서버에서는 커넥션을 물고 기다리고 있으며 이벤트의 업데이트가 있을 경우에 클라이언트로 응답을 보내주는 경우가 될 수 있다. 즉, 특정 이벤트가 일어날 경우에만 커넥션을 끊기 때문에 쓸데 없이 요청을 만들고 끊게 되는 일은 줄일 수 있는 것이다.


커넥션 개수에 따른 서버 메모리의 이슈와 브라우저에서 사용하는 최대 커넥션 개수에 대해서 어떤 영향을 미치게 될지에 대해서 이야기 해볼 수 있는데 이러한 이슈들은 뒷부분에서 다룰 것이고 여기서는 어떻게 롱폴링을 구현할 수 있는지에 대한 내용을 다루도록 하겠다.



롱폴링의 경우 서버에서 커넥션을 물고 있기 때문에 커넥션 관리 이슈를 빼놓고 생각해 볼 수 없다.기존의 폴링은 커넥션을 자주 연결하고 끊기 때문에 서버 트래픽이나 서버 CPU의 영향을 주게 된다면 커넥션을 물고 있을 경우 가장먼저 생각해 봐야 하는 것이 메모리 이슈이다. 


Connection 의 유효성을 체크해야 한다. ( 상시 )




요청과 응답이 많아지면 폴링보다 비용이 더커짐


응답을 지연하는과정에서 컨넥션을 유지하는데, 사용자가 많아지면 그만큼 비용이 발생


코드 구현 복잡도 및 유지보수에서의 관리가 똪리요


고대유물같은거 거의 사용하지않는다.


이 방식을 위해서는 연결된 커넥션과 요청 리스트들을 가지고 있어야 하는데요

오랫동안 연결되어 있는 커낵션을 최적하지 못하는 문제가 있습니다.


웹소켓


웹소켓


HTML5부터 추가된 것이 WebSocket입니다.


웹소켓은 TCP 소켓을 이용하여 지속적인 커넥션을 유지하고 자유롭게 양방향 통신이 가능합니다


폴링이나 롱폴링 방식과는 달리 지속적을 커넥션을 유지하고 필요한 데이터만 전송하므로 불필요한 헤더가 줄어듭니다


약 400배이상 Kbyte의 헤더크기를 byte수준으로 압축이 가능합니다. 그래서 네트위크의 과부하를 줄이고 에플리케이션의 반응성을 높일 수 있습니다




https://viewer.diagrams.net/?highlight=0000ff&edit=_blank&layers=1&nav=1&title=ddd.drawio#R7VlNc9owEP01HNNBlr84JpSk7UxnOuWQ3jqKvRhNhEVl8ZVfXymWsS2bxGEgTCBckFfrlfSenlYLPTycre8EmU9%2F8hhYz%2BnH6x7%2B2nMchEJPfWnLJrf42BgSQWPjVBrG9AmMsW%2BsCxpDVnOUnDNJ53VjxNMUIlmzESH4qu424aw%2B6pwk0DCMI8Ka1nsay2luDb1%2Baf8GNJkWI6O%2B6Xkg0WMi%2BCI14%2FUcPHn%2B5N0zUsQy%2FtmUxHxVMeFRDw8F5zJvzdZDYBrbArb8vdsdvdt5C0hllxcCEroRPEQohonvuVdOHmBJ2AKKFfhMhbqZ6laiW0NGdXRjV7HLLrMouSmAVOub6yasdfczMKCHRjqinDHTXE2phPGcRNp3pfbUNlZ1KWZ1SxAS1hWTWdod8BlIsVEuRa9vYC62oXlclZyigolphc%2FQ2IjZRsk2cgmlahg0uyGLOyA7BqEW9xGQ9dzTIfv974%2BrJ5ndpOEowPzP0rl1xRVqgddCDNL4Wp8N6inlKdRxyr0hbpwLFkhNRCpL9lpWXNgEMCLpsh6%2BDQYzwi9OtcgKwLcnhgHc9S0kM74QEZi3qoq3A6HBFy%2BsxUKuFUsSkYBsxHomZrvy%2FblqO2TOiSu%2FfyCuvIHiKhiUn5PS1naC7aYtYiTLaPSxmLNV5vT3ZM7eAo1AR%2BbK3Z1tcJFSfsO%2FBWS1RI53phuZ55kKl5kU%2FBGGnHFRqnRCGbNMhNEk1RtCUaySG77RWYaqu9a16ZjRONbDtOaqMrH1t9NqpKlOO8i8gIM6Myhopq6gZYc5x8pc%2FvnL6lU17C2rQTdZKfTIpuI21w7ZCxN22ye8c162%2F6Dmrxr5DA6q8aCDxu8JvTSB%2B57FhdsUuPueAg%2FPX%2BCBtf%2FxoQTeCHTkvDnooKnR0ip%2FL0FUxQ84BS%2FoxFkTva3g%2B5CqelUMnWs%2B57SqQm0VX%2FM6ms15msGFKcu%2Bjzqnvo%2BiC6zzMD5UvrIDHVtZn4VeV2GdPmV55y8sb2DdE%2FYWlnXhcDumrDdXevbFBr9S6dn%2B4TtUeqjtN4LPUq9R6hVkHKHUU4%2Flv3I5r%2BVfn3j0Hw%3D%3D


https://www.youtube.com/watch?v=gQyRxPjssWg&lc=z22uuri4xymychzdqacdp4312yzntlmbf50veklcmhpw03c010c.1607506361291415


http://blog.breakingthat.com/2019/04/04/java-collection-map-concurrenthashmap/


https://kamang-it.tistory.com/entry/JSPWebJavaLong-Polling%EC%9C%BC%EB%A1%9C-%EC%9B%B9-%EC%B1%84%ED%8C%85%EA%B5%AC%ED%98%84http-%EC%96%91%EB%B0%A9%ED%96%A5


https://www.youtube.com/watch?v=gQyRxPjssWg


https://medium.com/@icehongssii/%EA%B9%9C%EC%B0%8D%ED%95%9C-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8%EB%93%A4%EC%9D%84-%EC%9C%84%ED%95%9C-%EA%B0%84%EB%8B%A8%ED%95%9C-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EC%83%81%EC%8B%9D-2-2-http%EB%A5%BC-%EB%84%98%EC%96%B4%EC%84%9C-%EC%8B%A4%EC%8B%9C%EA%B0%84-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%82%B9websocket-c49125e1b5a0


https://mohwaproject.tistory.com/entry/%E3%85%81%E3%85%81%E3%85%81


http://dark0096.blogspot.com/2018/01/polling-vs-long-polling-vs-streaming.html


https://wedul.site/157


https://hoonsbara.tistory.com/80


https://yoonix.tistory.com/169



https://vnthf.github.io/blog/Front-What_is_comet/


https://m.blog.naver.com/khjzzangs/220407333401


https://bkim.tistory.com/3


https://medium.com/@alswns1201/spring-websocket-%EC%B1%84%ED%8C%85-c662b33dcb0b


https://github.com/ytw9699/Dokky/issues/185


https://wedul.site/157


https://lucasroesler.com/2018/07/golang-long-polling-a-tale-of-server-timeouts/

반응형

'Basic > 네트워크' 카테고리의 다른 글

프록시에 대한 이해  (0) 2020.08.15
통신, 네트워크, 프로토콜 개념  (0) 2020.08.09
HTTP 프로토콜의 특징(비연결성과 비상태성)  (0) 2019.12.10
구글로그인  (0) 2019.12.08
OAuth 2.0  (0) 2019.12.08