[NW]네트워크 개념 정리

Network

• OSI 7계층
• TCP/IP의 개념
• TCP/UDP
• TCP와 UDP
• TCP와 UDP의 헤더 분석
• TCP의 3-way-handshake와 4-way-handshake
• HTTP와 HTTPS
• HTTP 요청/응답 헤더
• CORS란?
• GET 메서드와 POST 메서드
• 쿠키와 세션
• DNS
• DNS Round Robin 방식
• 웹 통신의 큰 흐름
• REST와 RESTful의 개념
• 소켓 이란
• Socket.io와 WebSocket의 차이
• Frame, Packet, Segment, Datagram

OSI 7계층

1. 물리 계층 (Pyysical layer)
   • 네트워크의 기본 네트워크 하드웨어 전송 기술을 이룬다.
   • 네트워크의 높은 수준의 기능의 논리 데이터 구조를 기초로 하는 필수 계층이다.
2. 데이터 링크 계층 (Data link layer)
   • 주소 값은 물리적으로 할당 받는데, 이는 네트워크 카드가 만들어질 때부터 Mac address가 정해져 있다는 뜻이다.
   • 데이터 링크 계층의 가장 잘 알려진 예는 이더넷이다.
   • 데이터 전송 단위는 Frame이다.
3. 네트워크 계층 (Network layer)
   • 여러개의 노드를 거칠때마다 경로를 찾아주는 역할을 하는 계층으로 다양한 길이의 데이터를 네트워크들을 통해 전달하고, 그 과정에서 전송 계층이 요구하는 데이터 품질을 제공하기 위한 기능적, 정차적 수단을 제공한다.
   • 네트워크 계층은 라우팅, 흐름 제어, 세그멘테이션, 오류 제어 등을 수행한다.
   • 데이터 전송 단위는 Packet이다.
4. 전송 계층 (Transport layer)
   • 양 끝단의 사용자들이 신뢰성있는 데이터를 주고 받을 수 있도록 해 주어, 상위 계층들이 데이터 전달의 유효성이나 효율성을 생각하지 않도록 해준다.
   • 가장 잘 알려진 전송 계층의 예는 TCP이다.
   • 데이터 전송 단위는 Segment이다.
5. 세션 계층
   • 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공한다.
   • 동시 송수신 방식, 방이중 방식, 전이중 방식의 통신과 함께 체크 포인팅과 유휴, 종료, 다시 시작 과정 등을 수행한다.
6. 표현 계층
   • 코드 간의 번역을 담당하여 사용자 시스템에서 데이터의 형식상 차이를 다루는 부담을 응용 계층으로부터 덜어 준다.
7. 응용 계층
   • 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.
   • 일반적인 응용 서비스는 관련된 응용 프로세스들 사이의 전환을 제공한다.

TCP/IP의 개념

TCP와 UDP

UDP UDP(user Datagram Protocol, 사용자 데이터그람 프로토콜은 비연결형 프로토콜이다. IP데이터그램을 캡슐화하여 보내는 방법과 연결 설정을 하지 않고 보내는 방법을 제공한다. UDP는 흐름제어, 오류제어 또는 손상된 세그먼트의 수신에 대한 재전송을 하지 않는다. 이 모두가 사용자 프로세스의 몫이다. UDP가 행하는 것은 포트들을 사용하여 IP프로토콜에 인터페이스를 제공하는 것이다.

종종 크라이언트는 서버로 짧은 요청을 보내고, 짧은 응답을 기대한다. 만양 요청 또는 응답이 손실된다면, 클라이언트는 time out 되고 다시 시도할 수 있으면 된다. 코드가 간단할 뿐만 아니라 TCP처럼 초기설정 에서 요구되는 프로토콜보다 적은 메시지가 요구된다.

UDP를 사용하는 것들에는 DNS가 있다. 어떤 흐스트 네임의 IP주소를 찾을 필요가 있는 프로그램은, DNS 서버로 호스트 네임을 포함한 UDP패킷을 보낸다. 이 서버는 호스트의 IP 주소를 포함한 UDP패킷을 응답한다. 사전에 설정이 필요하지 않으며 그 후에 해제가 필요하지 않다.

TCP 대부분의 인터넷 응용 분야들은 신뢰성과 순차적인 전달을 필요로 한다. UDP로는 이를 만족시킬 수 없으므로 다른 프로토콜이 필요하여 탄생한 것이 TCP이다. TC{(Transmission Control Protocol, 전송제어 프로토콜) 는 신뢰성이 없는 인터넷을 통해 중단간에 신뢰성 있는 바이트 스트림을 전송 하도록 특별히 설계되었다. TCP서비스는 송신자와 수신자 모두가 소켓이라고 부르는 종단점을 생성함으로써 이루어진다. TCP에서 연결 설정(connection setablishment)는 3-way-handshake를 통해 행해진다.

모든 TCP연결은 전이중(full-duplex), 점대점(point-to-point) 방식이다. 전이중이란 전송이 양방향으로 동시에 일어날 수 있음을 의미하며 점대점이란 각 연결이 정확히 2개의 종단점을 가지고 있음을 의마한다. TCP는 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.

TCP와 UDP의 헤더 분석

TCP의 3-way-handshake와 4-way-handshake

HTTP와 HTTPS

HTTP의 문제점

• HTTP는 평문 통신이기 때문에 도청이 가능하다.
• 통신 상대를 확인하지 않기 떄문에 위장이 가능하다.
• 완전성을 증명할 수 없기 때문에 변조가 가능하다.
  위 세가지는 다른 암호화하지 않은 프로토콜에도 공통되는 문제점이다.

TCP/IP는 도엋이 가능한 네트워크이다.

TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신을 할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화 통신해야 한다.

보안 방법

1. 통신 자체를 암호화 SSL(Secure Socket Layer or TSL(Transport Layer Security라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화 할 수 있다. SSL을 조합한 HHTP를 HTTPS(HTTP Secure or HTTPS over SSL이라고 부른다.
2. 콘텐츠를 암호화 말 그대로 HHTP를 사용해서 운반하는 내용인, HTTP메시지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면 받는 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.

통신 상대를 확인하지 않기 떄문에 위장이 가능하다.

HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 때문에 누구든지 request를 보낼 수 있다. IP주소나 port등 에서 그 웹 서버에 액세스 제한이 없는 경우 request가 오면 상대가 누구든지 무언가의 리스폰스를 반환한다. 이러한 특징은 여러 문제점을 유발한다.

1. 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지를 확인할 수 없다.
2. 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지를 확인할 수 없다.
3. 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
4. 어디의에서 누가 리퀘스트 했는지 확인할 수 없다.
5. 의미없는 리퀘스트도 수신한다. —> DoS 공격을 방지할 수 없다. 보완 방법 위 암호화 방법으로 언급된 SSL로 상대를 확인할 수 있다. SSL은 상대를 수단하는 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이어트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 된다.

HTTPS

HTTP에 암호화와 인증, 그리고 완전성 보호를 더한 HTTPS.

HTTPS 는 SSL의 껍질을 덮어쓴 HTTP라고 할 수 있다. 즉, HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니라는 것 이다. HTTP통신하는 소켓 부분을 SSL or TLS라는 프로토콜로 대처하는 것 뿐이다. HTTP는 원래 TCP와 직접 통신했지만, HTTPS에 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다. SSL을 사용한 HTTPS는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.

모든 웹 페이지에서 HTTPS를 사용하지 않는 이유 평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스가 많이 필요하다. 통신할 때마다 암호화 하면 많은 리소그를 소비하기 때문에 소버 한 대당 처리할 수 있는 request의 수가 줄어들게 된다. 그렇기 때문에 민감한 정보를 다룰 때만 HTTPS에 의핸 암호화 통신을 사용한다.

HTTP 요청/응답 헤더

CORS란?

GET 메서드와 POST 메서드

둘 다 HTTP프로토콜을 이용래서 서버에 무엇인가를 요청할 때 사용하는 방식이다. 하지만 둘의 특징을 제대로 이해하고 기술의 목적에 맞게 알맞은 용도에 사용해야한다.
GET GET방식은 요청하는 데이터가 ‘HTTP Request Message’ 의 Header부분의 url에 담겨서 전송된다.
때문에 url상에 ‘?’뒤에 데이터가 붙어 request를 보내게 되는 것이다. 이러한 방식은 url이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적이다.
또 보안이 필요한 데이터에 대해서는 데이터가 그래도 url에 노출되므로 ‘GET’방식은 적절하지 않다.

POST POST 방식의 request는 ‘HTTP Message의 Body’부분에 데이터가 담셔서 전송된다. 때문에 바이너리 데이터를 요청하는 경우 POST방식으로 보내야 하는 것처럼 데이터 크리가 GET방식보다 크고 보안면에서 낫다.
(하지만 보안적인 측면에서는 암호화를 하지 않는 이상 고만고만 하다.)
그렇다면 이러한 특성을 이해한 뒤에는 어디에 적용되는지 알아봐야 그 차이를 극명하게 이해할 수 있다.
우선 GET은 가져오는 것이다. 서버에서 어떤 데이터를 가져와서 보여준다거나 하는 용도이지 서버의 값이나 상태 등을 변경하지 않는다. SELECT적인 성햐응ㄹ 갖고 있다고 볼 수 있는 것이다. 반면에 POST는 서버의 값이나 상태를 변경하기 위해서 또는 추가하기 위해서 사용된다.

부수적인 차이점을 좀 더 알아보면 GET방식의 요청은 브라우저에서 caching 할 수 있다. 때문에 POST방식으로 요청해야 할 것을 보내는 데이터의 크리가 작고 보안적인 문제가 없다는 이유로 GET방식으로 요청한다면 기존의 caching되었던 데이터가 응답될 가능성이 존재한다. 때문에 목적에 맞는 기술을 사용해야 한다.

쿠키와 세션

DNS

DNS Round Robin 방식

DNS Round Robin 방식의 문제점

1. 서버의 수 만큼 공인 IP주소가 필요함
   부하 분산을 위해 서버의 대수를 늘리기 위해서는 그 만큼의 공인 IP가 필요하다.
2. 균증하게 분산되지 않음
   모바일 사이트 등에서 문제가 될 수 있는데, 스마트폰의 접속은 캐리어 게이트웨이 라고 하는 프록시 서버를 경유 한다. 프록시 서버에서는 이름변환 결과가 일정 시간 동안 캐싱되므로 같은 프록시 서버를 경유 하는 접속은 항상 같은 서버로 접속된다. 또한 PC 용 웹 브라우저도 DNS 질의 결과를 캐싱하기 때문에 균등하게 부하분산 되지 않는다. DNS 레코드의 TTL 값을 짧게 설정함으로써 어느 정도 해소가 되지만, TTL 에 따라 캐시를 해제하는 것은 아니므로 반드시 주의가 필요하다.
3. 서버가 다운되도 확인 불가
   DNS서버는 웹 서버의 부하나 접속 수 등의 상황에 따라 질의결과를 제어할 수 없다. 웹 서버의 부하가 높아서 응답이 느려지거나 접속수가 꽉 차서 접속을 처리할 수 없는 상황인 지를 전혀 감지할 수 가 없기 때문에 어떤 원인으로 닫운되더라도 이를 검출하지 못하고 유저들에게 제공한다. 이 때문에 유저들은 간혹 다운된 서버로 연결이 되기도 한다. DNS round robin은 어디까지나 부하분산을 위한 방법이지 다중화 방법은 아니다.

weighted round-robin
각각의 웹 서버에 가중치를 가미해서 분산 비율을 변경한다. 물론 가중치가 큰 서버일수록 빈번하게 선택되므로 처리능력이 높은 서버는 가중치를 높게 설정하는 것이 좋다.

least-connection
접속 클라이언트 수가 가장 적은 서버를 선택한다. 로드밸런서에서 실시간으로 connection수를 관리하거나 각 서버에서 주기적으로 알려주는 것이 필요하다.

웹 통신의 큰 흐름

REST와 RESTful의 개념

소켓 이란

Socket.io와 WebSocket의 차이

Frame, Packet, Segment, Datagram