WebSocket을 사용할 수 있는데 왜 AJAX를 사용합니까?

나는 한동안 WebSockets를 사용해 왔으며, Node server와 WebSockets를 활용하여 University의 마지막 해 프로젝트를위한 Agile 프로젝트 관리 도구를 만들기로 결정했습니다. WebSocket을 사용하면 응용 프로그램이 처리 할 수있는 초당 요청 수가 624 % 증가했습니다.

그러나 프로젝트를 시작한 후 보안 허점을 읽었으며 일부 브라우저는 기본적으로 WebSockets를 사용하지 않도록 선택했습니다.

이것은 나를 질문으로 인도합니다.

WebSockets가 대기 시간과 리소스 오버 헤드를 줄이는 데 큰 도움이 될 때 AJAX를 사용하는 이유는 무엇입니까? AJAX가 WebSockets보다 나은 기능이 있습니까?

WebSockets는 AJAX를 대체하기위한 것이 아니며 Comet / long-poll을 대체하기위한 것이 아닙니다 (이것이 의미가있는 경우가 많지만).

WebSockets의 목적은 브라우저와 서버간에 지연 시간이 짧은 양방향 양방향 전이중 연결을 제공하는 것입니다. WebSockets는 HTTP 및 AJAX (대화식 게임, 동적 미디어 스트림, 기존 네트워크 프로토콜에 브리징 등)를 사용하여 실제로 불가능했던 브라우저 애플리케이션에 대한 새로운 애플리케이션 도메인을 엽니 다.

그러나 WebSocket과 AJAX / Comet 간에는 의도적으로 겹치는 부분이 있습니다. 예를 들어, 브라우저에 서버 이벤트 (예 : 푸시)를 알리려면 Comet 기술과 WebSockets가 모두 가능한 옵션입니다. 애플리케이션에 지연 시간이 짧은 푸시 이벤트가 필요한 경우 이는 WebSocket에 유리합니다. 반면에 기존 프레임 워크 및 배포 된 기술 (OAuth, RESTful API, 프록시,로드 밸런서)과 공존해야하는 경우에는 현재 Comet 기술에 유리합니다.

WebSockets가 제공하는 특정 이점이 필요하지 않은 경우 AJAX 및 Comet과 같은 기존 기술을 사용하는 것이 더 좋습니다. 이는 기존의 거대한 도구, 기술, 보안 메커니즘 에코 시스템을 재사용하고 통합 할 수 있기 때문입니다. , 지식 기반 (즉, 스택 오버플로에 더 많은 사람들이 WebSockets보다 HTTP / Ajax / Comet을 알고 있음) 등

반면, HTTP / Ajax / Comet의 대기 시간 및 연결 제한 내에서 제대로 작동하지 않는 새 애플리케이션을 작성하는 경우 WebSocket 사용을 고려하십시오.

또한 일부 답변은 WebSocket의 단점 중 하나가 제한된 / 혼합 서버 및 브라우저 지원이라는 것을 나타냅니다. 조금만 확산시켜 보겠습니다. iOS (iPhone, iPad)는 여전히 이전 프로토콜 (Hixie)을 지원하지만 대부분의 WebSocket 서버는 Hixie 및 HyBi / IETF 6455 버전을 모두 지원합니다 . 대부분의 다른 플랫폼 (내장 지원이없는 경우)은 web-socket-js (Flash 기반 polyfill) 를 통해 WebSocket 지원을받을 수 있습니다 . 여기에는 대다수의 웹 사용자가 포함됩니다. 또한 서버 백엔드에 노드를 사용하는 경우 web-socket-js를 폴백으로 포함 하는 Socket.IO 를 사용하는 것이 좋습니다. 이를 사용할 수 없거나 사용할 수없는 경우 Comet 기술이 사용 된 것으로 돌아갑니다. 주어진 브라우저에서 사용할 수 있습니다.

업데이트 : iOS 6은 현재 HyBi / IETF 6455 표준을 지원합니다.

2017 년 12 월로, 웹 소켓은 (실제적으로) 모든 브라우저에서 지원되며 그 사용은 매우 일반적입니다.

그러나 이것이 웹 소켓이 특히 HTTP / 2 적응이 증가함에 따라 AJAX를 적어도 완전히 대체하지 못했음을 의미하지는 않습니다.

짧은 대답은 AJAX는 여전히 웹 소켓을 사용하는 경우에도 대부분의 REST 애플리케이션에 유용하다는 것입니다. 그러나 신은 세부 사항에 있습니다.

폴링에 대한 AJAX?

폴링 (또는 긴 폴링)을 위해 AJAX를 사용하는 것은 소멸되고 있습니다. 그러나 두 가지 좋은 이유 (주로 작은 웹 앱의 경우)로 여전히 사용 중입니다.

1. 많은 개발자들에게 AJAX는 특히 백엔드 코딩 및 디자인과 관련하여 코딩하기가 더 쉽습니다.

2. HTTP / 2를 사용하면 AJAX (새로운 연결 설정)와 관련된 최고 비용이 제거되어 AJAX 호출이 특히 데이터 게시 및 업로드에있어 성능이 뛰어납니다.

그러나 Websocket 푸시는 AJAX보다 훨씬 우수합니다 (헤더를 다시 인증하거나 재전송 할 필요가없고 "데이터 없음"왕복 등이 필요 없음). 이것은 여러 번 논의 되었습니다.

REST를위한 AJAX?

AJAX의 더 나은 사용법은 REST API 호출입니다. 이렇게하면 코드 기반이 간소화되고 Websocket 연결이 차단되지 않습니다 (특히 중간 크기의 데이터 업로드에서).

REST API 호출 및 데이터 업로드에 AJAX를 선호 하는 몇 가지 강력한 이유가 있습니다 .

1. AJAX API는 실제로 REST API 호출을 위해 설계되었으며 매우 적합합니다.

2. AJAX를 사용한 REST 호출 및 업로드는 클라이언트와 백엔드에서 코딩하기가 훨씬 쉽습니다.

3. 데이터 페이로드가 증가함에 따라 메시지 조각화 / 멀티플렉싱 논리가 코딩되지 않으면 Websocket 연결이 차단 될 수 있습니다.

   단일 Websocket send호출 에서 업로드가 수행 되면 업로드가 완료 될 때까지 Websocket 스트림을 차단할 수 있습니다. 이렇게하면 특히 느린 클라이언트에서 성능이 저하됩니다.

일반적인 디자인은 Websocket을 통해 전송되는 작은 bidi 메시지를 사용하는 반면 REST 및 데이터 업로드 (클라이언트에서 서버로)는 AJAX의 사용 편의성을 활용하여 Websocket이 차단되지 않도록합니다.

그러나 대규모 프로젝트에서는 Websocket이 제공하는 유연성과 코드 복잡성과 리소스 관리 간의 균형이 Websocket에 유리하게 균형을 이룰 것입니다.

예를 들어, Websocket 기반 업로드는 연결을 끊고 다시 설정 한 후 큰 업로드를 재개 할 수있는 기능을 제공 할 수 있습니다 (업로드하려는 5GB 동영상을 기억하십니까?).

업로드 조각화 로직을 코딩하면 중단 된 업로드를 재개하기가 쉽습니다 (어려운 부분은 코딩하는 것임).

HTTP / 2 푸시는 어떻습니까?

HTTP / 2 푸시 기능이 웹 소켓을 대체하지 못하거나 대체 할 수 없다는 것을 추가해야합니다.

이것에 대해서는 이전 에 논의 했지만 단일 HTTP / 2 연결이 전체 브라우저 (모든 탭 / 창)에 제공되므로 HTTP / 2에 의해 푸시되는 데이터는 자신이 속한 탭 / 창을 알지 못합니다. Websocket의 데이터를 특정 브라우저 탭 / 창으로 직접 푸시하는 기능을 대체 할 수있는 기능이 없습니다.

Websocket은 소규모 양방향 데이터 통신에 적합하지만 AJAX는 특히 많은 페이로드 (업로드 등)를 고려할 때 여전히 많은 장점을 가지고 있습니다.

그리고 보안?

글쎄, 일반적으로 프로그래머에게 더 많은 신뢰와 통제가 제공 될수록 도구는 더욱 강력 해지고 보안 문제는 더욱 커집니다.

보안은 브라우저의 코드에 내장되어 있기 때문에 AJAX는 본질적으로 우위를 차지할 것입니다 (때로는 의심 스럽지만 여전히 존재합니다).

반면에 AJAX 호출은 "중간자 공격"에 더 취약한 반면 웹 소켓 보안 문제는 일반적으로 보안 결함을 도입 한 응용 프로그램 코드의 버그입니다 (일반적으로 백엔드 인증 논리는 이러한 부분을 찾을 수 있습니다).

개인적으로 나는 Websockets가 약간 더 나쁘다고 생각되면, 특히 당신이하는 일을 알고있을 때 이것이 큰 차이가 아니라고 생각합니다.

내 겸손한 의견

IMHO, REST API 호출 이외의 모든 용도로 웹 소켓을 사용합니다. 빅 데이터 업로드 가능하면 조각을 만들어 웹 소켓을 통해 보냅니다.

IMHO의 폴링은 불법이며 네트워크 트래픽 비용은 끔찍하며 Websocket 푸시는 새로운 개발자도 쉽게 관리 할 수 ​​있습니다.

IE10부터 WebSockets가 지원되므로 이전 브라우저 (IE9 포함)의 문제 외에도 투명 프록시, 리버스 프록시 및로드 밸런서를 포함하여 아직 WebSocket을 지원하지 않는 네트워크 중개자에게는 여전히 큰 문제가 있습니다. WebSocket 트래픽을 완전히 차단하는 (즉, HTTP UPGRADE 명령 이후) 일부 이동 통신사가 있습니다.

몇 년이지나면서 WebSockets는 점점 더 많이 지원 될 것이지만 그 동안에는 항상 브라우저로 데이터를 전송하기위한 HTTP 기반 폴백 방법이 있어야합니다.

내가 웹 소켓과 보안에 대해 읽은 대부분의 불만은 웹 브라우저 보안 및 방화벽 보안 도구의 보안 공급 업체가 제공 한 것입니다. 문제는 HTTP에서 websocket 이진 프로토콜로 업그레이드 한 후에 패킷 내용과 그 의미가 응용 프로그램에 따라 다르기 때문에 (웹 프로그램 트래픽에 대한 보안 분석을 수행하는 방법을 모른다는 것입니다). 이것은 모든 인터넷 트래픽을 분석하고 분류하는 데 기반을 둔 생계를 유지하는 이들 회사에게는 명백한 악몽입니다. :)

WebSocket은 구형 웹 브라우저에서 작동하지 않으며 이를 지원하는 브라우저 는 종종 구현 방식이 다릅니다. 그것이 AJAX 대신 항상 사용되지 않는 유일한 이유입니다.

필자는 웹 소켓과 HTTP가 라이벌이 아니거나 동일한 문제를 해결하지 않기 때문에 웹 소켓과 HTTP를 명확하게 비교할 수 없다고 생각합니다.

웹 소켓은 거의 실시간으로 오래 지속되는 양방향 데이터 스트리밍을 처리하는 데 탁월한 선택이며 REST는 가끔 통신에 적합합니다. 웹 소켓을 사용하는 것은 상당한 투자이므로 가끔 연결하는 데 너무 많은 부담이됩니다.

로드가 많을 때 Websocket이 더 잘 작동한다는 것을 알 수 있습니다. HTTP는 캐싱을 활용할 수 있기 때문에 약간 더 빠릅니다. REST를 웹 소켓과 비교하는 것은 사과를 오렌지와 비교하는 것과 같습니다.

우리는 어느 것이 우리 애플리케이션에 더 나은 솔루션을 제공하는지 확인해야하며, 어느 것이 우리의 사용 사례에 가장 적합한 지 확인해야합니다.

REST API와 같은 Websocket 엔드 포인트 및 클라이언트의 Websocket과 같은 RESTful 엔드 포인트를 처리 할 수있는 클라이언트 크기 lib 형식의 HTTP와 Websocket의 차이점에 대한 예입니다. https://github.com/mikedeshazer/sockrest 또한 클라이언트에서 웹 소켓 API를 사용하려고하거나 그 반대로 사용하려는 사람들을 위해. libs / sockrest.js는 거의 차이점을 명확하게합니다.