WebSockets를 사용할 수 있는데 AJAX를 사용하는 이유는 무엇입니까?
WebSockets를 사용한 지 꽤 되었기 때문에, Node 서버와 WebSockets를 활용한 대학에서의 마지막 해 프로젝트의 신속한 변화를 위한 프로젝트 관리 툴을 작성하기로 결정했습니다.WebSockets 를 사용하면, 애플리케이션이 처리할 수 있는 초당 요청수가 624%증가하는 것을 알 수 있었습니다.
그러나 프로젝트를 시작한 이후 보안상의 허점과 일부 브라우저는 기본적으로 WebSockets를 비활성화하는 것을 선택하고 있습니다.
그러면 다음과 같은 질문이 나옵니다.
WebSockets가 대기 시간과 리소스 오버헤드를 줄이는 데 탁월한 역할을 하는 것 같은데, AJAX가 WebSockets보다 더 나은 기능을 하는 것이 있습니까?
WebSockets는 AJAX를 대체하는 것이 아니며 Comet/long-poll을 대체하는 것도 아닙니다(많은 경우 이치에 맞지만).
WebSockets의 목적은 브라우저와 서버 간에 저지연, 양방향, 전이중 및 장기 실행 연결을 제공하는 것입니다.WebSockets는 HTTP 및 AJAX(대화형 게임, 동적 미디어 스트림, 기존 네트워크 프로토콜에 대한 브리징 등)를 사용하여 실제로 가능하지 않았던 브라우저 애플리케이션에 새로운 애플리케이션 도메인을 개방합니다.
그러나 WebSockets와 AJAX/Comet 사이에는 분명 목적이 중복됩니다.예를 들어 브라우저가 서버 이벤트에 대해 알림(즉, 푸시)을 받고자 하는 경우 Comet 기법과 WebSockets는 모두 실행 가능한 옵션입니다.응용 프로그램에서 지연 시간이 짧은 푸시 이벤트가 필요한 경우 웹소켓에 유리한 요소가 됩니다.한편, 기존 프레임워크 및 배치된 기술(OAuth, RESTful API, 프록시, 로드 밸런서)과 공존해야 하는 경우, 이는 (현재로서는) Comet 기술을 선호하는 요인이 됩니다.
WebSockets가 제공하는 구체적인 이점이 필요하지 않은 경우 AJAX나 Comet과 같은 기존 기술을 그대로 사용하는 것이 좋습니다. 이를 통해 도구, 기술, 보안 메커니즘, 지식 기반(즉, AJAX)을 재사용하고 통합할 수 있기 때문입니다.stackoverflow의 사용자가 WebSockets보다 HTTP/Ajax/Comet을 훨씬 더 많이 알고 있습니다.
한편, HTTP/Ajax/Comet의 지연 시간 및 연결 제약 조건 내에서 제대로 작동하지 않는 새로운 애플리케이션을 만들고 있다면, WebSockets의 사용을 고려해 보십시오.
또한 WebSockets의 단점 중 하나는 서버와 브라우저의 지원이 제한적이거나 혼재되어 있다는 답변도 있습니다.내가 그것을 조금 확산시켜볼게.iOS(iPhone, iPad)는 여전히 이전 프로토콜(Hixie)을 지원하지만, 대부분의 WebSockets 서버는 Hixie와 HyBi/IETF 6455 버전을 모두 지원합니다.대부분의 다른 플랫폼(아직 내장 지원이 없는 경우)은 웹 소켓-js(플래시 기반 폴리필)를 통해 WebSockets 지원을 받을 수 있습니다.이것은 대부분의 웹 사용자를 대상으로 합니다.또한 서버 백엔드에 노드를 사용하는 경우 소켓 사용을 고려하십시오.I/O는 web-socket-js를 폴백으로 포함하며, 그마저도 사용할 수 없는 경우(또는 비활성화되어 있는 경우) 해당 브라우저에서 사용할 수 있는 Comet 기술을 사용합니다.
업데이트: iOS 6는 현재 HiBi/IETF 6455 표준을 지원합니다.
2017년 12월로 거슬러 올라가면, 웹소켓은 (실제로) 모든 브라우저에서 지원되며, 그 사용은 매우 일반적입니다.
그러나 이는 웹소켓이 적어도 완전히 AJAX를 대체했다는 것을 의미하지는 않습니다. 특히 HTTP/2 적응이 증가하고 있기 때문입니다.
간단히 말하면 AJAX는 웹소켓을 사용하는 경우에도 대부분의 REST 애플리케이션에 적합합니다.하지만 신은 디테일에 있어, 그래서...:
폴링용 AJAX?
폴링(또는 긴 폴링)에 대한 AJAX의 사용은 사라지고 있지만(그럴 필요가 있다), 두 가지 타당한 이유(주로 소규모 웹 애플리케이션용)로 인해 여전히 사용되고 있다.
많은 개발자들에게 AJAX는 특히 백엔드를 코딩하고 설계할 때 코드화하기가 더 쉽습니다.
HTTP/2에 의해, AJAX(새로운 접속의 확립)와 관련된 최고 코스트가 없어져, 특히 데이터의 투고와 업로드를 위해서 AJAX 콜의 퍼포먼스가 향상되었습니다.
그러나 웹 소켓 푸시는 AJAX보다 월등히 우수합니다(헤더를 재인증 또는 재발송할 필요 없음, "데이터 없음" 라운드 트립 등).이것은 여러 번 논의되었다.
휴식은 아약스?
AJAX에서는 REST API 콜을 사용하는 것이 좋습니다.이를 통해 코드 베이스가 단순해지고 웹 소켓 접속이 차단되는 것을 방지합니다(특히 중간 크기의 데이터 업로드 시).
REST API 호출 및 데이터 업로드에 AJAX를 선호하는 이유는 다음과 같습니다.
AJAX API는 사실상 REST API 호출용으로 설계되었으며 매우 적합합니다.
클라이언트와 백엔드 양쪽에서 AJAX를 사용한REST 콜 및 업로드를 훨씬 쉽게 코드화할 수 있습니다.
데이터 페이로드가 증가하면 메시지 조각화/멀티플렉싱 로직이 코딩되지 않는 한 웹 소켓 연결이 차단될 수 있습니다.
의 웹 1개
send업로드가 완료될 때까지 웹 소켓 스트림을 차단할 수 있습니다.이로 인해 특히 속도가 느린 클라이언트에서 성능이 저하됩니다.
공통 설계에서는 웹소켓을 통해 전송되는 작은 Bidi 메시지를 사용하는 반면 REST 및 데이터 업로드(클라이언트에서 서버로)는 AJAX의 사용 편의성을 활용하여 웹소켓의 차단을 방지합니다.
그러나 대규모 프로젝트에서는 웹소켓이 제공하는 유연성과 코드 복잡성과 리소스 관리 간의 균형이 웹소켓에 유리하게 작용할 것입니다.
예를 들어 웹 소켓 기반 업로드에서는 연결이 끊어졌다가 다시 설정된 후 대용량 업로드를 재개할 수 있습니다(업로드하고자 하는 5GB 동영상 기억하십니까?).
업로드 단편화 로직을 코딩하면 중단된 업로드를 재개하기 쉽습니다(하드 파트는 코딩이었습니다).
HTTP/2 푸시는 어떻습니까?
HTTP/2 푸시 기능은 웹소켓을 대체할 수 없습니다(아마도 그럴 수 없습니다).
이는 이전에도 설명했지만 하나의 HTTP/2 접속이 브라우저 전체(모든 탭/윈도우)에 서비스를 제공하므로 HTTP/2에 의해 푸시되는 데이터는 어떤 탭/윈도우에 속하는지 알 수 없으므로 특정 브라우저 탭/윈도우에 데이터를 직접 푸시하는 Websocket의 기능을 대체할 수 없습니다.
웹소켓은 작은 양방향 데이터 통신에 적합하지만, 특히 더 큰 페이로드(업로드 등)를 고려할 때 AJAX는 여전히 많은 이점을 가지고 있습니다.
보안은?
글쎄요, 일반적으로 프로그래머에게 더 많은 신뢰와 통제가 주어질수록, 도구는 더 강력해집니다...보안에 대한 우려가 높아집니다.
AJAX의 보안은 브라우저 코드에 내장되어 있기 때문에 당연히 AJAX가 우위에 있습니다(때로는 의문스럽지만 아직 존재합니다).
한편, AJAX 콜은 「man in the middle」공격의 영향을 받기 쉬운 반면, Websockets의 시큐러티 문제는, 통상, 시큐러티 결함을 초래한 애플리케이션 코드의 버그입니다(보통 백엔드 인증 로직은 이러한 문제를 발견할 수 있는 장소입니다.
개인적으로 웹소켓이 좀 더 나은 것 같다면, 특히 당신이 무엇을 하고 있는지 알고 있을 때, 저는 이것이 큰 차이가 아니라고 생각합니다.
나의 겸손한 의견
IMHO, 나는 REST API 호출을 제외한 모든 것에 웹소켓을 사용할 것이다.빅 데이터 업로드는 가능하면 단편화하여 웹소켓을 통해 전송합니다.
폴링(IMHO)은 금지해야 합니다.네트워크 트래픽 비용은 엄청나며 웹 소켓 푸시는 신규 개발자도 쉽게 관리할 수 있습니다.
IE9를 포함한 이전 브라우저의 문제 외에도 웹소켓이 IE10부터 지원되기 때문에 투명 프록시, 리버스 프록시, 로드 밸런서 등 아직 웹소켓을 지원하지 않는 네트워크 매개체에는 여전히 큰 문제가 있습니다.일부 모바일 통신사는 WebSocket 트래픽을 완전히 차단합니다(즉, HTTP UPGRADE 명령어 이후).
시간이 지남에 따라 WebSockets는 점점 더 많이 지원되지만, 그 동안은 항상 브라우저에 데이터를 보내기 위한 HTTP 기반의 폴백 방식을 사용해야 합니다.
웹소켓과 보안에 관한 불만사항의 대부분은 웹브라우저 보안 및 방화벽 보안 툴의 보안 벤더가 제공한 것입니다.문제는 웹소켓 트래픽이 HTTP에서 웹소켓 바이너리 프로토콜로 업그레이드되면 패킷의 내용과 의미가 애플리케이션에 따라 달라지기 때문에 웹소켓 트래픽의 보안 분석 방법을 모른다는 것입니다.모든 인터넷 트래픽을 분석하고 분류하는 것이 생계형인 이들 기업에게 이는 분명히 로지스틱 악몽이다.:)
WebSockets는 오래된 웹브라우저에서는 동작하지 않습니다.또, WebSockets를 서포트하는 브라우저는, 실장이 다른 경우가 많습니다.그것이 바로 AJAX 대신 항상 사용되지 않는 좋은 이유입니다.
웹소켓과 HTTP는 라이벌도 아니고 같은 문제를 해결할 수도 없기 때문에 명확하게 비교할 수 없다고 생각합니다.
웹소켓은 긴 수명 양방향 데이터 스트리밍을 거의 실시간으로 처리하는 데 매우 적합한 반면, REST는 가끔 사용하는 통신에 적합합니다.웹소켓을 사용하는 것은 상당한 비용이 들기 때문에 가끔 접속하는 경우에는 과잉입니다.
웹소켓은 부하가 높을 때 성능이 향상되지만 캐시를 사용할 수 있기 때문에 HTTP가 약간 더 빠를 수 있습니다.REST와 웹소켓을 비교하는 것은 사과와 오렌지를 비교하는 것과 같습니다.
어떤 솔루션이 애플리케이션에 더 적합한지, 어떤 솔루션이 우리의 사용 사례에 가장 적합한지 확인해야 합니다.
REST API와 같은 웹 소켓 끝점과 클라이언트의 웹 소켓과 같은 RESTful 끝점을 처리할 수 있는 클라이언트 크기 lib 형식의 HTTP와 웹 소켓 간의 차이점의 예입니다.또한 https://github.com/mikedeshazer/sockrest 클라이언트 상에서 웹 소켓 API를 사용하려는 고객 또는 그 반대도 익숙한 방식으로 사용하려는 고객에게는 적합합니다.libs/sockrest.js는 그 차이를 거의 명확하게 합니다(혹은 그렇게 해야 합니다).
언급URL : https://stackoverflow.com/questions/10377384/why-use-ajax-when-websockets-is-available
'programing' 카테고리의 다른 글
| 휴지 상태를 사용하여 Oracle에서 대용량 BLOB(100MB 이상)를 유지하는 방법 (0) | 2023.03.23 |
|---|---|
| jQuery에서 항목을 배열에 추가하려면 어떻게 해야 합니까? (0) | 2023.03.23 |
| AJAX & jQuery에서 django 폼을 게시하는 방법 (0) | 2023.03.23 |
| 새 봄 MVC 프로젝트를 위한 Tymeleaf와 Angular 중 선택 (0) | 2023.03.23 |
| Angular에서 $scope 액세스JS 공장? (0) | 2023.03.23 |