굳건하게

안녕하세요, 여행벌입니다.

오늘은 가장 중요한 프로토콜인 HTTP 에 대해서 정리해보겠습니다.

 [ 웹 ( Web ) ]

 WWW( World Wide Web ) 은 인터넷에 연결된 사용자들이 서로 정보를 공유할 수 있는 공간을 의미합니다.

 인터넷이랑 웹은 다른 개념으로 인터넷상의 하나의 서비스가 웹입니다. 이러한 WWW를 구성하는 기술로, 문서 기술 언어로는 HTML, 문서 전송 프로토콜로는 HTTP, 문서의 주소 지정 방법으로는 URL 을 사용 중입니다.

프로토콜

컴퓨터와 네트워크 기기가 상호간에 통신하기 위해서는 서로 같은 방법으로 통신을 해야한다. 어떻게 상대를 찾고, 어떻게 상대에게 이야기를 시작하고, 어떠한 언어로 이야기를 하며, 어떻게 이야기를 종료할까와 같은 규칙이 프로토콜이다.

[ HTTP 프로토콜 역사 ]

 WWW 에서 문서 전송 프로토콜로 처음 등장했다. HyperText MarkUp Language 인 HTML을 전송하는 프로토콜로 시작했지만, 현재는 HTTP 메시지에 모든 것을 전송하고 있고 심지어 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.

• HTTP/0.9 1991년 GET 메서드만 지원, HTTP 헤더X
• HTTP/1.0 1996년 메서드, 헤더 추가
• HTTP/1.1 1997년 현재에도 가장 많이 사용되고 있는 버전, TCP 프로토콜 기반
  • RFC2068(1997) -> RFC2616(1999) ->RFC7230~7235(2014)
  • 2014년도에 개정된 버전이 현재 사용중인 버전이다.
• HTTP/2 2015년 TCP 프로토콜 기반, 성능 개선
• HTTP/3 ~ING TCP 대신에 UDP를 사용해서 성능 개선에 초점

[ 클라이언트 서버 구조 ]

 HTTP는 기본적으로 클라이언트 - 서버 구조로 작동해서 역할이 명확히 구분되어있다. 리소스를 요청하는 쪽이 클라이언트, 리소스를 제공하는 쪽이 서버가 된다. 역할이 명확히 구분되어있으므로 서로 상대가 무슨 일을 하는지 신경 쓸 필요가 없다. 리소스 요청을 리퀘스트, 리소스 반환을 리스폰스 라고 한다.

참고 : 리퀘스트 없는 리스폰스는 없다!

[ 무상태프로토콜 ( stateless ) ]

 HTTP 프로토콜은 상태를 유지하지 않는 스테이트리스 프로토콜입니다. HTTP 프로토콜 독자적으로, 리퀘스트와 리스폰스를 교환하는 동안에 상태를 관리하지 않습니다. 결국, HTTP 프로토콜 레벨에서는 이전에 보냈던 리퀘스트나 이미 되돌려준 리스폰스에 대해서는 전혀 기억하지 않습니다.

• 장점 : 서버 확장성이 높음(스케일 아웃) --> 서버를 확장해야될 때 기존의 상태를 기억할 필요가 없다!
• 단점 : 클라이언트가 추가 데이터를 계속 전송해줘야됨.

참고 !

웹이 발전함에 따라 스테이리스 특성만으로는 처리하기 어려운 상황이 생겨서 이를 해결하는 쿠키, 세션이 등장함!

[ 비연결프로토콜 ( connectionless ) ]

 HTTP 프로토콜은 리퀘스트가 발생하면 연결을 하고 리스폰스를 보낸 후 연결을 끊습니다.

 따라서, 서버 자원을 매우 효율적으로 사용할 수 있습니다. 리퀘스트를 요청한 모든 클라이언트와 계속 연결 상태를 유지하게 된다면 추가 리퀘스트를 보내지 않는 클라이언트들이 서버 자원을 낭비하게됩니다.

ex) 쇼핑몰 사이트에 들어가서 옷을 검색!(리퀘스트) --> 검색결과(리스폰스) --> 결과로 반환된 옷을 구경하면되지 연결상태 필요 X

[ 지속연결 ( Persistent Connections ) ]

HTTP 프로토콜은 비연결프로토콜이므로 트랜스포트, 네트워크 계층에서 TCP, IP 프로토콜을 통해 매번 연결을 새로 맺어야하는 문제가 있습니다. 또, 요즘은 하나의 웹 페이지에서도 HTML, CSS, JS 등 많은 리소스가 다운로드되어야하므로 매번 새로운 연결을 하는 것은 비효율적입니다.

이 문제를 해결하기 위해 HTTP/1.1 에서는 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지하는 지속연결 기능을 제공해줍니다.

이상으로, HTTP 기본 내용 정리를 마치겠습니다.

안녕하세요, 여행벌입니다.

오늘은 저번 IP(인터넷프로토콜)에 이어서 TCP / UDP 프로토콜에 대해서 정리해보겠습니다.

TCP / UDP 프로토콜은 인터넷 계층의 트랜스포트 계층에서 사용되는 프로토콜로 서로 다른 장/단점을 지니고 있습니다.

[ TCP 프로토콜 (전송 제어 프로토콜) ]

TCP 프로콜은 Transmission Control Protocol 의 약자로 전송 제어 프로토콜입니다. IP 프로토콜의 여러 문제점들을 해결해주는 프로토콜로 대용량의 데이터를 보내기 쉽게 작게 분해하여 상대에게 보내고, 제대로 도착했는지 확인하는 프로토콜입니다. 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등의 내용을 포함하고 있습니다.

• 연결지향 - 3 way handshake
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜

[ TCP 3 way handshake ]

TCP 프로토콜은 데이터를 보낼 상대가 받을 수 있는 상태인지 확인하기 위해 3-Way-Handshake 기법을 사용합니다. 물리적으로 연결되는 것이 아니라 논리적으로 연결하는 과정으로 IP 프로토콜의 비연결성 문제를 해결합니다.

3-Way-Handshake는 SYN ACK 라는 TCP 플래그를 이용해 패킷이 보내졌는지 여부를 확인하는 방법입니다. 

( SYN : 접속요청 / ACK : 요청수락 )

과정은 다음과 같습니다.

​ 1) 클라이언트는 서버에 접속을 요청하는 SYN 패킷을 보냅니다.

​ 2) 서버는 클라이언트의 요청인 SYN 패킷을 받고, 클라이언트에게 요청을 수락한다는 ACK 패킷과 SYN 패킷을 보냅니다.

​ 3) 클라이언트는 서버의 수락 응답인 ACK 패킷과 서버가 보낸 SYN 패킷을 받고 SYN 패킷을 잘 받았다고 ACK 패킷을 서버로 보냅니다.

클라이언트가 SYN 플래그로 상대에게 접속함과 동시에 패킷을 보내고, 서버는 SYN/ACK 플래그로 클라이언트에 접속함과 동시에 패킷을 받은 사실을 전합니다. 마지막으로 클라이언트가 ACK 플래그를 보내 패킷 교환이 완료되었음을 전합니다.

참고!

물리적으로 연결된거는 아님! 가상 연결!

[ TCP 4 way handshake ]

TCP 프로토콜에서는 연결을 끊기 위해서 4-Way-Handshake 기법을 사용합니다.

​ 1) 클라이언트가 TCP Header의 flags 필드의 FIN 을 셋팅하여 연결을 종료하겠다는 FIN 플래그를 전송합니다.

​ 2) FIN 플래그를 받은 서버는 ACK 패킷을 전송하고 서버를 CLOSE_WAIT 상태로 TimeOut을 겁니다.

​ 3) 서버는 데이터를 모두 보내고 통신이 끝났으면 연결이 종료되었다고 클라이언트에게 FIN 플래그를 전송합니다.

​ 4) 클라이언트는 FIN 플래그를 확인했다는 ACK 패킷을 서버로 보내고 서버는 ACK 패킷을 받고 연결을 close 합니다.

TCP Header에는 Code Bit(flag bit) 라는 6Bit 짜리 Bit 가 존재하고, Urg-Ack-Psh-Rst-Syn-Fin 순서로 해당 패킷이 어떤 내용을 담고 있는 패킷인지를 나타내는 비트가 존재합니다.

SYN : Synchronize Sequence Number

ACK : ACKnowledgement

[ PORT ]

같은 IP 내에서 프로세스를 구분하는 주소입니다. 같은 IP 주소에 있는 여러 개의 애플리케이션을 구분하기 위해 등장한 개념으로 TCP 프로토콜은 PORT 정보를 가지고 있습니다.

• 0 ~ 65535 할당 가능
• 0 ~ 1023 : 잘 알려진 포트 --> 사용하지 않는 것이 좋음!
• HTTP - 80포트
• HTTPS - 443포트

IP를 아파트, PORT를 몇동 몇호 라고 생각하자!

[ UDP 프로토콜 (사용자 데이터그램 프로토콜) ]

UDP 프로토콜은 IP프로토콜과 크게 다르지는 않습니다. PORT 정보랑 체크섬 정보만 추가되서 연결을 보장하지 않고, 데이터 전달 보증, 순서 보장을 모두 지원해주지 않습니다. 하지만 그만큼 TCP 프로토콜에 비해 빠르기 때문에 HTTP3에서는 UDP 프로토콜을 기반으로 동작합니다.

참고!

기존에는 대부분 TCP 프로토콜 기반이였으나 HTTP3에서는 UDP 프로토콜 기반!

[ DNS ( 도메인 네임 시스템 ) ]

IP 주소는 외우기도 어렵고, 변경될 수도 있으므로 IP 주소로 통신하는데 어려움이 있었습니다. 그래서 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 해주는 시스템인 도메인 네임 시스템이 등장했습니다.

[ URI (Uniform Resource Identifier) ]

네트워크 상에서 자원이 어디있는지를 알려주는 규약을 URI 라고 합니다. 우리가 흔히 자주 사용하는 URL 은 URI에 포함된 개념이고 URN 과 URL 이 합쳐져서 URI 가 되는데 URN 은 사용하지 않으므로 URI를 URL로 이해해도 괜찮습니다.

• Uniform : 리소스를 식별하는 통일된 방식
• Resource : URI로 식별할 수 있는 모든 것
• Identifier : 다른 항목과 구분하는데 필요한 정보

URI 는 로케이터(locator), 이름(name) 또는 둘 다 이용해서 자원을 식별.

URL 은 로케이터(locator) 으로 자원을 식별

URN 은 이름(name) 으로 자원을 식별

이상으로 TCP / UDP 프로토콜 정리를 마치겠습니다.

참고

- 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식

- 그림으로 배우는 HTTP&Network Basic

안녕하세요, 여행벌입니다.

그동안 공부에 집중을 하느라 git에만 정리를 하고 블로그 포스팅을 못하고 있었습니다.

다시 그동안 공부한 내용에 대해서 블로그에 차근차근 정리하며, 댓글도 답해보도록 하겠습니다!

이번 포스팅에서는 네트워크의 기본이 되는 인터넷이란 무엇인지, 인터넷에서 사용하는 IP 프로토콜이란 무엇인지에 대해서 다뤄보도록 하겠습니다.

[ 인터넷이란 ]

 우리가 자연스럽게 사용하고 있는 인터넷이란 무엇일까요??

 인터넷은 여러 통신망을 하나로 연결한다는 의미의 inter-network 라는 말에서 시작되었으며, 전 세계 컴퓨터들을 하나로 연결하는 거대한 컴퓨터 통신망을 의미합니다. 여러 컴퓨터가 각각 클라이언트와 서버로써 서로 연결되어 구성된 망을 컴퓨터 네트워크라고 하고, 인터넷은 이러한 컴퓨터 네트워크가 전 세계적인 규모로 이루어진 일종의 컴퓨터 네트워크 시스템입니다.

 우리가 미국에 있는 친구 노트북과 내 노트북으로 SNS 로 메시지를 주고받을 수 있는 것도 물리적으로 네트워크 기기들이 연결이 되어있고 (해저광케이블 등!) 그렇게 형성된 인터넷을 이용하기 때문에 가능한 것입니다.

[ 인터넷 4계층 ]

 인터넷은 4개의 계층으로 이루어져 있습니다. 계층 구조로 형성되어있기 때문에, 문제가 생겼을 때 문제가 되는 계층만 파악하고 고치면 되므로 대처하기 편하다는 장점이 있습니다.

• 애플리케이션 계층 - HTTP, FTP
• 전송 계층 - TCP, UDP
• 네트워크 계층, 인터넷 계층 - IP
• 링크 계층 - LAN 장비

[ IP, 인터넷프로토콜 ]

 인터넷에서 서로 다른 컴퓨터가 어떻게 통신을 할까요??

 어떤 방식으로 통신을 주고받을지 정해놓은 규약을 IP (인터넷프로토콜) 이라고 합니다.

 인터넷 프로토콜은 기본적으로 다음과 같이 동작합니다.

• 지정한 IP주소에 패킷(Packet) 이라는 통신 단위로 데이터 전달
  • 즉, 인터넷 프로토콜의 역할은 개개의 패킷을 상대방에게 전달하는 것이다.
• IP 주소는 각 노드에 부여된 주소를 가리키고 MAC 주소는 각 네트워크 카드에 할당된 고유의 주소다. IP 주소는 변경 가능하지만 MAC 주소는 변경할 수 없고, IP 주소와 MAC 주소를 이용해 통신을 합니다.

 인터넷에서 통신을 할 때 여러 대의 컴퓨터와 네트워크 기기를 중계해서 상대방에게 도착합니다. (인터넷 망이 여러 중간 노드들로 이루어져 있기 때문에 ) 이때, ARP (Address Resolution Protocol )을 이용하는데 도착지의 IP 주소를 바탕으로 거쳐가야 하는 기기들의 MAC 주소를 조사해서 최종적으로 도착하게 됩니다.

꿀팁!

IP주소는 컴퓨터마다 서버한테 부여받은 자기의 주소라고 생각하면 편하다.

[ IP 인터넷프로토콜의 한계 ]

 인터넷 프로토콜은 다음과 같은 한계점들이 있습니다.

 먼저, 패킷을 보내고 싶은 상대가 서비스 불능 상태여도 알 수 없기 때문에 패킷을 전송하게 됩니다. 그럼 우리가 원하는 대로 상대방이 패킷을 받을 수가 없게 됩니다.

• 비연결성
  • 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송

 또, 패킷이 제대로 도착했는지 알 수 없습니다. 우리는 무수히 많은 중간 노드들을 통해서 상대방에게 패킷을 전송하기 때문에 중간에 무슨 문제가 있는지, 제대로 전달이 된 건지 알 수 없습니다. 또, 패킷을 순서대로 1, 2, 3 을 보냈는데 패킷 1,2,3이 각각 다른 중간 노드들을 거쳐서 간다면 패킷이 순서대로 전달되지 않습니다.

• 비신뢰성
  • 중간에 패킷이 사라질 수 있음. ( 중간 인터넷망에서 문제가 생길 수 있음 )
  • 패킷 순서를 보장하지 않음.

 마지막으로, IP 주소를 이용해서 상대방을 찾기 때문에 하나의 노트북에서 여러 애플리케이션을 실행 중이고 그중 채팅 애플리케이션을 통해 다른 IP 주소와 소통하고 있다면 상대방은 내 노트북의 어떤 애플리케이션에게 패킷을 전달해야 될지 알 수 없습니다.

• 프로그램 구분
  • 같은 IP를 사용하는 서버에서 통신하는 애플리케이션끼리 구분 불가능.

오늘은 인터넷이 무엇인지, 인터넷에서 통신하기 위해 사용하는 IP(인터넷 프로토콜)에 대해서 알아봤습니다.

IP (인터넷 프로토콜) 만으로는 많은 한계점이 있기 때문에, 다른 계층과 다른 프로토콜들이 추가로 등장했습니다.

다른 프로토콜에 대해서는 다른 포스팅에서 정리해보도록 하겠습니다.

참고

- 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식

- 그림으로 배우는 HTTP&Network Basic

STS를 이용해 Spring 프로젝트를 만들고 Hello-world를 띄워보는 중, run server를 하니 다음과 같은 에러를 마주침.

Multiple Contexts have a path of "/controller" 라고 해서 뭔가 경로가 겹친 것 같다고 생각.

Spring_Ex00 프로젝트를 먼저 run 하고, 새롭게 Spring_jEx00 프로젝트를 만든 후 run 하는 상황이라 2개의 프로젝트가 올라가있음.

--> run server 하고 싶은 프로젝트를 제외하고 날려보자!

Remove 한 후 다시 Run을 해보니까 다음과 같이 제대로 서버가 돌아간다.

그럼 Tomcat 서버에 여러 개의 프로젝트를 올려놓을 수는 없는건가.. 추가 구글링을 했지만 답을 찾지 못했다... ㅠㅠ 아시는 분 댓글로 지식 공유해주시면 감사합니다,,,