웹 소켓으로 인해 Ajax/CORS가 사용되지 않게 되었습니까?

웹 소켓으로 인해 Ajax/CORS가 사용되지 않게 되었습니까?

모든 웹 브라우저에서 웹 소켓을 사용할 경우 Ajax가 사용되지 않게 됩니까?

웹 소켓을 사용하여 실시간으로 데이터를 가져오고 업데이트할 수 있다면 Ajax가 필요한 이유는 무엇입니까?어플리케이션이 기동했을 때 데이터를 취득하기 위해서 Ajax를 사용해도, 잠시 후에 이 데이터가 변경되었는지 확인할 수 있습니다.

그리고 웹 소켓은 교차 도메인에서 사용 가능합니까, 아니면 동일한 소스에서만 사용 가능합니까?

WebSockets는 AJAX를 완전히 구식으로 만들지 않으며 WebSockets는 교차 도메인을 수행할 수 있습니다.

에이잭스

AJAX 메커니즘은 플레인 웹 서버에서 사용할 수 있습니다.가장 기본적인 수준에서 AJAX는 웹 페이지가 HTTP 요청을 만드는 방법일 뿐입니다.WebSockets는 훨씬 낮은 수준의 프로토콜이며 WebSockets 서버가 필요합니다(웹서버, 독립 실행형 또는 웹서버에서 독립 실행형 서버로 프록시됨).

WebSockets의 경우, 프레임과 payload는 애플리케이션에 의해 결정됩니다.클라이언트와 서버 간에 HTML/XML/JSON을 주고받을 수 있지만 강제로 전송하지는 않습니다.AJAX는 HTTP입니다.WebSockets는 HTTP 친화적인 핸드쉐이크를 가지고 있지만 WebSockets는 HTTP가 아닙니다.WebSockets는 HTTP보다 원시 소켓에 더 가까운 양방향 프로토콜입니다.WebSockets 페이로드 데이터는 현재 표준 버전에서는 UTF-8로 인코딩되지만 향후 버전에서는 변경/확장될 가능성이 있습니다.

따라서 모든 클라이언트가 기본적으로 WebSockets를 지원하는 세계에서도 AJAX 유형 요청은 항상 존재하게 될 것입니다.WebSockets는 AJAX를 사용할 수 없거나 약간 사용할 수 없는 상황을 해결하기 위해 노력하고 있습니다(WebSockets의 양방향성과 오버헤드가 훨씬 낮기 때문입니다).그러나 WebSockets가 AJAX가 사용되는 모든 것을 대체하는 것은 아닙니다.

크로스 도메인

예, WebSockets는 교차 도메인을 지원합니다.연결을 설정하기 위한 초기 핸드셰이크는 오리진 정책 정보를 전달합니다.Wikipedia 페이지에는 일반적인 핸드쉐이크의 예가 표시됩니다.http://en.wikipedia.org/wiki/WebSockets

이 문제를 몇 가지 질문으로 나누어 보겠습니다.

모든 웹 브라우저에서 웹 소켓을 사용할 경우 Ajax가 사용되지 않게 됩니까?

절대로 그렇지 않아요.WebSockets는 서버에 대한 원시 소켓 연결입니다.이는 보안상의 문제가 수반됩니다.AJAX 콜은 단순히 비동기입니다.나머지 페이지와 동일한 검증 절차를 따를 수 있는HTTP 요청

웹 소켓을 사용하여 실시간으로 데이터를 가져오고 업데이트할 수 있다면 Ajax가 필요한 이유는 무엇입니까?

단순하고 관리하기 쉬운 작업에는 AJAX를 사용할 수 있습니다.모든 사람이 단순히 비동기 요구를 허용하기 위해 소켓 연결을 보호하는 오버헤드를 원하는 것은 아닙니다.그것은 충분히 간단하게 처리할 수 있다.

어플리케이션이 기동했을 때 데이터를 취득하기 위해서 Ajax를 사용해도, 잠시 후에 이 데이터가 변경되었는지 확인할 수 있습니다.

물론이죠, 데이터가 바뀌면요.데이터가 변경되지 않거나 지속적으로 새로 고쳐지지 않을 수 있습니다.이것도 코드 오버헤드를 고려해야 합니다.

그리고 웹 소켓은 교차 도메인에서 사용 가능합니까, 아니면 동일한 소스에서만 사용 가능합니까?

교차 도메인 WebSockets를 사용할 수 있지만 WS 서버를 허용하려면 코드를 지정해야 합니다.도메인(호스트) 헤더에 액세스할 수 있으며, 이 헤더를 사용하여 요청을 수락/거부할 수 있습니다.수 있다.nc접속을 확실히 보호하려면 , 다른 방법으로 접속을 인증할 필요가 있습니다.

웹소켓에는 Ajax가 회피하는 확장성 측면에서 몇 가지 큰 단점이 있습니다.ajax는 요청/응답 메시지를 전송하고 연결을 닫으므로(..또는 잠시 후) 누군가가 웹 페이지에 남아 있으면 유휴 상태일 때 서버 리소스를 사용하지 않습니다.웹소켓은 데이터를 브라우저로 다시 스트리밍하기 위해 서버 리소스를 묶습니다.서버에는 동시에 열어 둘 수 있는 동시 접속 수에 제한이 있습니다.서버측 테크놀로지에 따라서는 소켓을 처리하기 위해 스레드를 묶을 수도 있습니다.따라서 웹소켓은 연결당 양쪽에서 더 많은 리소스를 필요로 합니다.클라이언트에 서비스를 제공하는 모든 스레드를 쉽게 소진할 수 있으며, 많은 사용자가 페이지에 앉아만 있으면 새로운 클라이언트가 들어올 수 없습니다.이것이 nodejs, vertx, netty가 실제로 도움이 될 수 있는 부분이지만, 그것들도 상한선이 있습니다.

또한 기본 소켓의 상태에 대한 문제 및 스테이트풀 컨버세이션이 진행되는 코드를 양쪽에서 쓰는 문제도 있습니다.이것은 스테이트리스이기 때문에 에이잭스 스타일과는 관계가 없습니다.웹소켓은 낮은 수준의 프로토콜을 생성해야 합니다. 이 프로토콜은 Ajax로 해결됩니다.지금은 심장 박동, 유휴 연결 닫기, 오류에 대한 재연결 등이 매우 중요합니다.AJAX는 스테이트리스이기 때문에 AJAX를 사용할 때는 해결할 필요가 없습니다.상태는 앱의 안정성과 서버 상태에 매우 중요합니다.사소한 일이 아닙니다.HTTP 이전에는 많은 상태 저장 TCP 프로토콜(FTP, telnet, SSH)을 구축했으며, 그 후 HTTP가 실행되었습니다.그 한계에도 불구하고 HTTP가 놀라울 정도로 쉽고 강력했기 때문에 아무도 그런 일을 많이 하지 않게 되었습니다.웹소켓은 상태 저장 프로토콜의 장단점을 다시 불러옵니다.마지막 회전을 하지 않았다면 곧 알게 될 거야

실시간 데이터 스트리밍이 필요한 경우 스트리밍된 데이터를 얻기 위해 서버를 폴링하는 것이 더 나쁘기 때문에 이 추가 오버헤드가 보증됩니다.다만, 유저의 조작만을 실시하는 경우는, UI 의 갱신이 필요하게 됩니다.응답이 송신되면 컨버세이션이 종료되고 추가 서버 리소스가 사용되지 않기 때문에 ajax는 더 쉽고 리소스 사용 빈도가 낮아집니다.그래서 저는 이것이 트레이드오프라고 생각합니다.건축가는 그들의 문제에 맞는 도구를 결정해야 합니다.AJAX가 자리를 잡고 웹소켓이 자리를 잡았습니다.

갱신하다

스레드에 대해서는 서버의 아키텍처가 중요합니다.기존의 멀티 스레드 서버(또는 프로세스)를 사용하고 있는 경우, 각 소켓 접속이 요구에 응답하기 위한 자체 스레드를 취득하는 경우, 웹소켓은 매우 중요합니다.각 연결마다 소켓이 있으며, 이러한 소켓이 너무 많으면 OS가 쓰러집니다.또한 스레드도 마찬가지입니다(프로세스의 경우도 마찬가지입니다).스레드는 소켓보다 무겁기 때문에 동시에 실행하는 스레드 수를 절약하려고 합니다.즉, 모든 소켓 간에 공유되는 고정 수의 스레드인 스레드 풀을 만듭니다.그러나 소켓이 열리면 스레드는 전체 대화에 사용됩니다.이러한 대화의 길이에 따라 새로운 소켓에 대한 스레드의 용도를 얼마나 빨리 변경할 수 있는 시간은 달라집니다.대화의 길이에 따라 확장성이 결정됩니다.그러나 스트리밍을 하는 경우 이 모델은 확장에 적합하지 않습니다.스레드/소켓 설계를 중단해야 합니다.

HTTP의 요청/응답 모델을 사용하면 새 소켓의 스레드를 매우 효율적으로 전환할 수 있습니다.요청/응답만 사용할 경우 이미 구축된 HTTP를 사용하여 웹소켓에서 이와 같은 것을 재실장하는 것보다 훨씬 쉽습니다.

웹소켓은 HTTP와 같이 요청/응답할 필요가 없으며 서버의 스레드 풀에 고정된 수의 스레드가 있고 모든 스레드를 활성 대화로 연결하는 동일한 수의 웹소켓이 있으면 데이터를 스트리밍할 수 있으므로 들어오는 새 클라이언트에 서비스를 제공할 수 없습니다.최대 용량에 도달했습니다.웹소켓과 스레드에서도 프로토콜 설계가 중요합니다.프로토콜은 사용자가 서버에서 스레드를 사용하지 않도록 대화 모델당 소켓당 스레드를 느슨하게 할 수 있습니다.

여기서 비동기식 단일 스레드 서버가 필요합니다.Java에서는 이 NIO를 Non-blocking IO라고 부릅니다.즉, 데이터 송수신이 콜을 실행하는 스레드를 차단하지 않는 소켓용 API입니다.

socket.read() 또는 socket을 호출할 때 기존의 블로킹소켓입니다write()는 데이터가 수신 또는 전송될 때까지 기다린 후 프로그램에 대한 제어를 반환합니다.즉, 다른 작업을 할 수 있을 때까지 소켓 데이터가 들어오거나 나갈 때까지 프로그램이 대기하고 있습니다.그래서 우리는 동시에 일을 할 수 있도록 스레드를 가지고 있습니다.클라이언트 Y로부터의 데이터를 기다리는 동안, 이 데이터를 클라이언트 X에 송신해 주세요.Concuracies는 서버에 대해 이야기할 때 게임 이름입니다.

NIO 서버에서는 단일 스레드를 사용하여 모든 클라이언트를 처리하고 콜백을 등록하여 데이터가 도착했을 때 통지합니다.예를들면

socket.read( function( data ) {
   // data is here! Now you can process it very quickly without waiting!
});

socket.read() 콜은 데이터를 읽지 않고 바로 반환되지만, 제공된 함수는 수신 시 호출됩니다.이 설계는 코드 구축 및 설계 방법을 근본적으로 바꿔놓습니다. 왜냐하면 무언가를 기다리는 동안 시간을 끌면 새로운 클라이언트를 받을 수 없기 때문입니다.당신은 한 번에 두 가지 일을 할 수 없는 하나의 실이 있어요!당신은 그 한 가닥을 계속 움직여야 합니다.

NIO, Asynchronous IO, Event based 프로그램은 매우 복잡한 시스템 설계입니다.처음에는 이것을 써보는 것은 추천하지 않습니다.매우 상급 프로그래머도 견고한 시스템을 구축하는 것은 매우 어려운 일입니다.비동기이므로 차단 API를 호출할 수 없습니다.DB에서 데이터를 읽거나 다른 서버로 메시지를 보내는 것과 같이 비동기적으로 수행해야 합니다.파일 시스템에서 읽기/쓰기 작업을 수행해도 단일 스레드의 속도가 느려져 확장성이 저하될 수 있습니다.일단 비동기화되면 단일 스레드를 계속 이동하려면 항상 비동기화됩니다.이는 결국 DB와 같은 API가 비동기화되지 않아 더 많은 스레드를 채택해야 하기 때문에 어려운 문제입니다.따라서 하이브리드 접근 방식은 비동기 환경에서도 일반적입니다.

좋은 소식은 이미 구축된 하위 수준의 API를 사용하는 다른 솔루션이 있다는 것입니다.NodeJS, Vertx, Netty, Apache Mina, Play Framework, Twisted Python, Stackless Python 등C++를 위한 잘 알려지지 않은 라이브러리가 있을지도 모르지만, 솔직히 저는 그렇게 하고 싶지 않습니다.서버 테크놀로지는 CPU 바운드 이상의 IO바인드이기 때문에 가장 빠른 언어를 필요로 하지 않습니다.다이하드 퍼포먼스 너트인 경우 Java를 사용합니다.코드 커뮤니티가 넓어 속도가 C++보다 매우 가깝습니다(때로는 더 우수합니다).싫으면 Node나 Python으로 하세요.

네, 맞아요.:D

앞선 답변들은 상상력이 부족하다.웹소켓을 사용할 수 있다면 AJAX를 사용할 이유가 없습니다.

언급URL : https://stackoverflow.com/questions/4042691/web-sockets-make-ajax-cors-obsolete