들어가기 앞서

저번에 조사했던 http, 소켓 통신 등 여러 통신방식에 대한 정보를 필요로 했던 회의가 여러가지 이슈로 미뤄져 좀 더 조사해보게 되었다. 추가할 내용이 많아 따로 적어본다.

자바스크립트 기반의 웹 서비스에서 실시간으로 데이터를 주고받아야 할 필요성이 있다는게 핵심 요구 사항인데, 그러면 웹 소켓을 써야겠지만 짧은 내 생각으로는 꼭 소켓 통신을 써야하나? 라는 생각도 들고 여러가지 방법을 자세하게 조사해 달라는 말도 있어서 여러 방식을 알아봤다.

1) HTTP 통신

클라이언트가 요청하는 데이터를 서버에서 HTTP 통신 이용하여 전달

API 형식을 작성하여 클라이언트가 API 형식에 따라 데이터 요청하고 받아서 처리

웹 개발을 하는 사람이 데이터를 받고 원하는 형태로 가공하여 화면에 보여줌

서버는 제공하고자 하는 데이터나 기능을 제어할 수 있는 API로 만들면, 접근 권한이 있는 프로그램이 API를 통해 서버에서 제공하는 데이터를 요청해 사용 가능

클라이언트는 서버가 제공하는 API에 원하는 정보를 요청해 데이터를 받고 UI 등의 형태로 사용자에게 정보 제공

3. SSE

서버에서 클라이언트로 변경이 필요한 데이터를 전송해주는 SSE (Server-sent Events) 기술 존재

서버에서 클라이언트에 업데이트가 필요한 시점에 단방향으로 데이터를 제공하므로 주식, 날씨 정보 등의 업데이트에 유용

IE에서 지원하지 않는다는 단점 존재하나, polyfill (브라우저에서 지원하지 않는 API 플러그인이나 자바스크립트로 흉내 내 구현)로 해결 가능

3) HTTP 통신과 소켓 통신의 차이

HTTP 통신은 클라이언트가 요청해야 서버가 응답

서버로부터 응답받은 후에는 연결 종료

소켓 통신은 특정 포트를 통해 양방향 통신

HTTP 통신에 비해 더 많은 리소스 소모

지속적인 양방향 데이터 통신처럼 보이기 위해서 http 통신은 계속해서 데이터 요청하는 polling 방식 사용

사실상 실시간 연결은 아니므로 대부분 연결이 길어지면 단방향 통신으로 설계되어 헤더가 무거운 http 통신 특성상 여러 문제 발생

소켓 통신이 실시간으로 데이터를 주고받는 상황에서 http 통신에 비해 더 유리하지만, 실시간 기능이 필요하지 않은 상황에 적용 시 http 통신에 비해 비용이 크기 때문에 적절한 선택 필요

4) DB

DB 서버를 기반으로 서비스에 필요한 데이터 제공

DB 접속 권한을 클라이언트나 웹서버에 부여하고 DB 서버에 데이터를 요청해 받아오기 위해 클라이언트나 웹서버에서 위의 HTTP 통신이나 소켓 통신 등을 구현하여 데이터를 제공

내 생각으로는 데이터를 주고받는다면 보통 DB가 기반이기 때문에, 사실상 DB와 어떤 방식으로 통신할지를 결정하는 것

들어봤던 용어들도 정확하게 알고 가야할것 같다.

수업때 들어봤지만 잘 기억도 안나고, 모드버스 프로토콜을 공부하며 나오는 말들을 좀 더 알아보았다.

[네트워크]

라우팅
경로 정보를 분석해 현재 네트워크에서 다른 네트워크로 최적의 경로를 계산해
데이터를 전송하는 기법.

라우팅 테이블 : 토폴로지, 트래픽 부하 여부, 링크 비용 등 계산에 필요한 요소 기반으로
라우팅 프로토콜을 통해 계산된 라우팅 정보 저장된 테이블.

정적 라우팅 -> 관리자가 패킷 경로 수동으로 구성
동적 라우팅 -> 라우터가 라우팅 프로토콜의 계산에 따라 스스로 경로 결정

[참고] https://steady-coding.tistory.com/528

게이트웨이
다른 네트워크로 가기위한 관문. 같은 LAN 안에서는 MAC Address로 통신하기 때문에
게이트웨이 주소를 몰라도 상관없음.
자신의 네트워크 (ex: 192.168.0.1) 에서 다른 네트워크 (ex: 172.16.20)로 간다고 생각하면,
IPv4 마지막 주소인 192.168.0.xx 4번째 자리 주소가 네트워크의 갯수.
그 안에 게이트웨이 주소가 세팅되어 있어야 정상적으로 통신이 가능.
(subnet mask에서 단말의 수를 보고 네트워크의 수를 계산해서...)

[참고] https://ja-gamma.tistory.com/entry/%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4%EB%9E%80

시리얼 통신

serial(직렬) <-> parallel(병렬)
시리얼 통신에서는 데이터를 이진 펄스 형태로 전송. 
1: 논리 high, 0: 논리 low
Transmitter가 이진 펄스 형태로 보내고, Receiver가 높고 낮음 구분해 데이터로 읽는다.

이렇게 통신하려면 Transmitter와 Receiver가 Clock 동기화가 되어있어야함.
Clock: 어떤 시점에 이진 펄스를 논리 정보로 읽을것인지 시점 정하는 기준.
동기화가 안되어있으면 같은 데이터라도 이상하게 읽을 수 있다.
-> Clock Synchronization. 시리얼 통신에 꼭 필요하다. (interface에 따라 동기, 비동기)

Baud Rate: Trasmitter(이하 T)와 Receiver(이하 R) 사이의 초당 전송 bits 수.
일반적으로 9600인데, 1200, 2400, 4800, 57600 등 다양하게 씀.

Framing: 데이터 프레임. 시작과 정지 비트를 포함한 문자. 일반적으로 8 bits 사용

Error Control: 노이즈에 영향 주는 요소가 시리얼 통신에 많음. parity bits 검사.

동기 시리얼 프로토콜 : USB, CAN, SPI, I2C, Microwire
비동기 시리얼 프로토콜 : RS232, RS422, RS485

[참고] https://medium.com/newworld-kim/%EC%8B%9C%EB%A6%AC%EC%96%BC-serial-%ED%86%B5%EC%8B%A0%EC%9D%B4-%EB%AD%98%EA%B9%8C-bdf991a300b1

웹과 앱의 통신 방법에 대해 알아봐야 했다.

따로 알아봐야 해서 내가 몰랐던 다른것이 있는줄 알았다.

근데 다 알면서 몰랐던 것이라 정리했던걸 남겨놔보자.

1) HTTP 통신

API로 서버에서 던져주는게 제일 편하지 않을까?
클라이언트가 원하는 데이터가 있을건데
그게 웹이든, 앱이든 api로 요청하고 받아서 처리하고
그러면 구현해야 하는 일 -> API 작성 및 통신 구현
그리고 HTTP 통신.
JSON 형태로 데이터 주고받는다.

-> 이건 많이 해본거.

근데 API를 써보기만 하고 막상 자세히 뜯어서 공부해본 적은 없어서, 그냥 API를 써서 통신하면 되지않나?

라는 멍청한 생각을 하고있었다. 

API가 특별한 어떤 통신 방법이 아니다.

API는 HTTP 요청을 백엔드에 보냈을 때 실행되는 백엔드 기능.
프론트에서 HTTP라는 길을 통해 게시물 데이터를 백엔드에 보내 저장.
그럼 게시물이 아닌 다른 데이터는 어떻게 저장? -> 여러개의 HTTP 길 필요. 각 요청마다 담당자 필요.
여기서 이 담당자 -> API
API는 기능. 기능은 곧 함수. 백엔드 개발자가 만든 함수 = API.
API에 요청할 때 보내는 데이터는 API 함수로 들어갈 인자이고, 응답으로 받게되는 데이터가 API 함수의 return 데이터이다.

API의 요청 결과 타입이 JSON (JavaScript Object Notation)

https://velog.io/@sehee-xx/HTTP-%ED%86%B5%EC%8B%A0%EA%B3%BC-API

API에 대한 설명은 위의 글을 참고했다. 가장 이해가 잘되는 설명이었다.

2) 소켓 통신

실시간으로 주고받는다.
소켓으로 연결, 서버와 통신
node.js에 socket.io --> 얘가 웹 소켓 안될땐 자동으로 http long-polling 대체.
하지만 소켓 통신 방식으로 개발한다 -> 보안 문제 신경 많이 써야한다(CORS, SSL인증서 등).

3) DB

DB서버에서 요청받고 데이터를 처리해 쿼리로 날려주던가

예전에 알바했던 곳은 DB에서 JSON으로 뽑아내서 처리하도록 했었는데 굳이 그렇게 할 이유는 없었던것 같다.

4) FTP

파일을 통신하는데 쓴다?? 왜??

============================================================================================

이렇게 네가지 방식이 주로 논의되었다.

DB와 HTTP 통신이 아무래도 제일 무난한 것 같고, 실시간으로 연결을 유지하며 데이터를 보여주려면 소켓 통신도 가능한 옵션이라고 생각된다.

근데 FTP는 P2P 사이트 같은데서 쓰는 방식인것 같은데, 이걸 통신 방법으로 채택해서 서비스한다? 이건 좀..

뭔가 좋은 비유가 생각이 나진 않지만, 좋은 방식은 아니라고 판단된다. 

어쩌다 보니 네트워크에 대해 어느정도 알고있어야 하게 되었다.

그래서 공부한 내용을 메모장에만 적긴 아까워서 옮겨놓기로 했다.

원래는 이 블로그에 게임 개발을 공부하면서 포트폴리오 처럼 남겨놓으려고 했는데..

한게 없으니 당연히 적을것도 없고, 이제와서 아무 내용이나 그냥 되는대로 적기로 했다. 

내가 얼마나 게으른진 내가 제일 잘 알아서 얼마나 적을지도 대충 알겠지만 다시 해봐야할듯.