제가 사용하는 언어가 많이 언급됨에 먼저 양해를 구합니다. 의미전달이 잘 되었으면 좋겠습니다.
Web
(Web, WebBroswer, HTTP, HTML)
웹 : HTTP 프로토콜을 기반으로 한, 인터넷에 연결된 컴퓨터를 이용해 사람들과 정보를 공유
웹 브라우저 : 웹이라는 공간을 갈 수 있는 방법, 포탈, 창구, 응용 프로그램의 총칭
W3C : 웹 표준을 개발하는 국제 컨소시엄.
HTTP : 하이퍼텍스트를 빠르게 교환하기 위한 프로토콜의 일종으로 즉, HTTP는 서버와 클라이언트의 사이에서 어떻게 메시지를 교환할지를 정해놓은 규칙인 것이다.
HTML : 웹 페이지의 모습을 기술하기 위한 약속.
도메인 : (인터넷) 주소. 웹을 가미한다면 웹 사이트를 지칭하기 위해 의미를 확장한 단어.
URL: Uniform Resource Locator : 인터넷상의 각종 자원을 통일된 방식으로 표현하는 주소.
프로토콜 : 원활한 교류를 위해 만들어진 의례, 약속, 규칙, 법
ex.) HTTP, HTTPS, FTP, SMTP, Telnet, TCP, UDP, SSH, SSL, SOAP, WS, IPFS
프로토콜을 동일선상에 놓는 행위를 하지 말자. API와는 성격이 다르다.
학창 시절, 수학시간에 정의 공리 에를 배운 것을 기억하는가?
이들의 공통 분모(성격)에 프로토콜이라는 단어가 들어갈 뿐이다. 각각의 프로토콜들의 이해관계를 다 파악하기란 굉장히 어려울 것이다.
=> 굳이 해보겠다면, 이제야 계층에 대해 공부할 자격을 얻었다.
[OSI 7 계층](계층 링크)
<웹에 관한 질문 모음>
웹은 HTTP 프로토콜 만을 따른다. (?)
웹의 기반인 HTTP 프로토콜에는 웹 브라우저에서 웹소켓을 엔터쳐서 들어가는 방식이 허가지 되지 않는 규칙이 있다. (?)
WS 프로토콜에는 웹 브라우저에서 주소를 직접 입력해(엔터쳐서) 들어가는 방식이 허가되지 않는 규칙이 있다. (?)
=> 이에 대해 정확한 답을 모르지만 오답의 명제는 얼마든지 찾아 거를 수 있다.
웹의 기반인 HTTP 프로토콜에는 다른 프로토콜이 접근이 안되는 규칙이 있다. (X)
=> 나는 WS 프로토콜 기반인 웹소켓을 웹서버에서 사용하고 있다.
웹소켓은 웹에서 사용할 수 있는 소켓이다. (O)
=> 내가 그렇게 알고 있으나, 이가 사실이 아니어 접속이 가능할 수도, 후에 프로토콜이 업데이트가 되어 가능할 수도 있다. 사실유무를 말하려는 것이 아니라, 그러한 규칙들이 프로토콜이라는 것이다.
=> 엔터쳐서 접속이 불가하다면, 실제 서비스를 고려한다면 HTTP(S) 프로토콜을 따르는 웹서버(Express In NodeJS)에다 직접 코드를 입력해 연결을 하는 방식이 제안될 것이다.
=> 물론 매번 , 한계가 있다. 그럼에도 최대한의 효율을 낼 수 있는 오답을 파악하는 방법을 나는 채택하고 있는 것이다.
계속 하기 전에 서버에 대해 짚고 넘어간다.
서버 : 클라이언트에게 네트워크를 통해 서비스하는 컴퓨터.
좀 더 벗겨내 원천을 보면, 서버라는 단어가 성립이 되려면 두가지가 필요하다.
하나의 무언가(혹은 사람, 컴퓨터, 노드 등의 어떠한 것), 그리고 무언가와의 관계
이 구조가 없다면 서버라는 단어는 선언될 수 없다.
서버의 종류로 FTP, 웹, 데이터베이스를 살펴보면 이해가 더 수월할 것이다.
암튼 서버, 클라이언트, 관계가 나왔다. 이 상황에서 물어볼 수 있는 질문을 웹으로 예를 들면.
웹 서버는 ?
뭐를 위한 서버에요? : 웹
클라이언트 : 나
서버 : 나와 관계가 있는 사람. 나한테 뭘 줄 사람
어디서 만나요 : 웹에서
거긴 어떻게 갈 수 있어요 : 웹 브라우저로
그럼 웹 서버는 어떻게 킬거에요? : 나의 경우라면 Express 라이브러리로
Express 는 어떻게 켜요? : NodeJS에서
NodeJS 는 어떻게 켜요? : 내 컴퓨터로
컴퓨터는 어디서 사요? : 용산에서
=> 웹을 굳이 예로 언급한 것은, 웹이 모든 이에게 제일 친숙하니까. 웹은 적어도 내가 죽을 때까지는 안망하지 않을까?
=> 하나의 주제에 조예가 깊다면 장점은 다른 것과 융합이 가능하다는 것이다. 그런데 그 주제가 제일 친숙하고 많이 쓴다? 말 끝난 것 같은데
=> HTTP 자체가 TCP(HTTP/ 1, 2)를 사용하나, 이제는 UDP 프로토콜(HTTP/ 3) 또한 사용한다. 이로써 앞서 제기했던 HTTP 프로토콜 만을 사용한다. 는 사실이 아니었다.
=> 학부 때 지도교수님께서 하셨던 말씀은 기계공학만으로는 답이 없으니 다른 것과 융합을 잘해보세요 였다. (의역이 심합니다. 정말 그렇구나 하시면 안됩니다... 죄송합니다.)
=> 웹 1.0, 2.0, 3.0 과 다른 개념이다.
웹 1.0, 2.0, 3.0 :
런타임 환경 : 어떠한 것들을 실행할 수 있는 환경, 장소
NodeJS : 자바스크립트 런타임 환경. 자바스크립트 언어를 실행할 수 있는 환경.
SOAP와 REST 는 동일선상이 아니다.
SOAP : HTTP, HTTPS, SMTP 등의 프로토콜을 사용하여 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 통신 프로토콜.
REST : Representational State Transfer, 네트워크 소프트웨어 아키텍쳐. 쉽게 말해 네트워크에서 통신을 구성할 때 이런 구조로 설계하라는 지침. 아버지의 가슴어린 충고랄까. 규칙은 아니다. 제일 많이 쓰지 않는가? 정말 자세히 수십번을 곱씹어야 할 것이다.
API : Application Programming Interface. 쉽게 말해 가져다 쓰라고 만들어낸 모든 것. 이게 가장 쉬운 설명이 아닐까 싶다.
REST(ful) API : REST라는 아버지 말씀을 잘 따르는(ful 한) 웹 API.
=> REST + API의 결합으로 굳어진 것일 뿐이지, 저런 단어가 어느 기업이나 단체에서 제시하고 있는 것은 아니다.
=> 정리한다면, 업비트에서 내 거래 정보를 가져온다는 것은 데이터를 가져오기(API) 위해 적절한(REST를 만족하는) 입력을 행한 것. 왜 그렇게 입력했나? 업비트가 RESTful하게 제공하고 있으니까
더 나아가보자.
WS : 웹에서 소켓 통신(TCP, UDP)를 사용하기 위한 프로토콜.
웹소켓 : 사용자의 브라우저와 서버 사이의 인터랙티브 통신 세션을 설정할 수 있게 하는 고급 기술, + 웹 API.
Socket.io : 클라이언트 서버간 리얼타임 웹 애플리케이션을 위한 자바스크립트 라이브러리.
=> 기술이고, 라이브러리니까 동일 선상에 둘 수는 있겠다.
=> 하지만, 같지는 않다. Socket.io는 웹소켓 구현체가 아니다
=> 가능한 경우라면 전송에 있어 웹소켓을 이용하지만, 각각의 패킷에 추가 메타데이터가 들어간다.
=> 그래서 웹소켓 클라이언트는 Socket.io 서버에 연결할 수 없다.
=> Socket.io 클라이언트 역시 웹소켓과 통신할 수 없다.
=> 클라이언트, 서버 모두 Socket.io로 가던가, 웹소켓으로 가던가
=> 이더리움 네트워크 상에서 모든 인스턴스들이 상호작용을 할 수 있는 것과 대비된다.
=> 정리해서, WS 프로토콜을 기반으로 구축된 어떠한 것, 거기에 추가로 + HTTP 롱 폴링 또는 자동 재연결에 대한 폴백과 같은 것들도 보장을 하는 기능을 넣은 것.
=> 웹 소켓의 지원여부로 인해 Socket.io를 택하는 경우도 많지만, WebRTC처럼 지원 수준이 다르니 제공 라이브러리를 아예 사용하라고 권고하기도 한다.
P2P : 중앙 서버를 거치지 않고 클라이언트 컴퓨터끼리 직접 통신하는 방식, 통신망.
=> P2P의 기반에 있는 프로토콜이 BitTorrent, KAD (Cademlia), Ed2k (eDonkey2000 network) 등이 있는 것.
=> P2P와 웹소켓 또한 동일 선상에 둘 수 없다.
블록체인 : 분산 컴퓨팅 기술 기반의 데이터 위변조 방지 기술.
=> 데이터 관련 기술. 정의는 여기서 말이 끝나야 한다는 소리다.
WebRTC : Web Real-Time Communication, 웹 브라우저와 모바일 애플리케이션 간 리얼타임 커뮤니케이션을 위한 웹 API. 즉, 저거하려면 가져다 쓰세요.
=> p2p 커뮤니케이션이다. 생성된 인스턴스들이 클라이언트-서버의 관계가 아님.
=> 구글 껍니다
web3.js : Ethereum JavaScript API
=> HTTP, IPC, WS 프로토콜을 사용하여 로컬, 이더리움 노드 간에 상호작용을 위한 자바스크립트 API
=> 웹에서 다 사용이 가능한 API이라 WebRTC와 web3.js는 같은 선상에 둘 수 있겠다
=> 만든 사람은 다름.
팁 하나만,
크게 한번 정리한다고 하면, 사용할 API를 고려하고 수집하는 과정을 거친다면,
각각의 공식 docs에서 어떠한 제시를 하는지 꼭 고려를 해야합니다.
노드 환경에서 좀 더 쉽게 예제를 들면서 설명을 해보죠.
처음 자바스크립트를 배우며 HTML 쌩으로 하드 코딩 했을 때
<script> 태그를 씌워 제이쿼리던, 무엇을 불러온 기억이 있으시지 않나요.
=> 그 불러온 행위를 통해 a.html에서 여러 메서드를 사용한 것이죠.
=> 근데 그게 너무 노가다니까, 자바스크립트에 경우라면, 이를 js 파일로 빼고, .js에 코드를 적고 .html에 한번에 연결을 합니다.
=> 이제는 .html 만드는 것도 그것도 귀찮아서, 이제 여러 프레임워크 사용을 하게 된 것이죠. React, Vue, NextJS 등등을 말입니다.
WebRTC 예제에서 사용한 .captureStream()은 웹 APIs/HTMLMediaElement다. 스트림을 이용하려고 했는데 웹에 메서드가 있었다. 확인하자. .mozCaptureStream()은 파이어폭스를 위한 메서드 인 듯.
=> 클라이언트에서 바로 요청을 하는 경우인데 지금은, 이것으로 INFURA에서 데이터 가져오는 것을 클라이언트에서 행해도 부하가 없을까..? 일단 로그를 봐야할 것이고,
=> 그것이 부적합하다면, 서버에서 미리 요청을 해서 다시 클라이언트로 스트림을 쏴주는 경우가 적합할 텐데 이를 한번 봐보자.
=> 예제에는 서버에 관련된 내용이 없구나. 아항 일단 그럼 peerConnection을 봐보자
English (US)
RELATED TOPICS
internet explorer을 기억해보자
나 어렸을 때, 혹 본인이 나이가 어리다면 응답하라 시리즈를 떠올리자
천리안
나우누리
하이텔
이 있었다.
그럼 얘네는 주소가 있었나?
있었을 것이다.
주소입력을 하던, 지금의 클릭이던
웹3
