굳건하게

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

오늘은 HTTP 에서 지원해주는 다양한 메소드에 대해서 정리해보겠습니다.

[ HTTP 메소드 ]

HTTP 는 다양한 메소드를 지원해줍니다.

• GET : 리소스 조회
• POST : 요청 데이터 처리
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제
• HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS : 대상 리소스에 대한 통신 기능 옵션을 설명
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

[ GET 메소드 ]

GET 메소드는 리퀘스트 URI로 식별된 리소스를 가져올 수 있도록 요구하는 메소드입니다. 가져올 리소스 내용은 지정된 리소스를 서버가 해석한 결과입니다.

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많으므로 사용 X
• ( 최근 스펙에서는 바디에 데이터를 넣는 것을 허용했지만, 실무에서는 사용 X )

[ POST 메소드 ]

POST 메소드는 엔티티를 전송하고 엔티티 처리를 요구하는 메소드입니다. POST 메소드는 GET메소드와 함께 가장 많이 사용되는 메소드로 GET 메소드는 아니지만 어떤 메소드를 사용해야될 지 모르겠으면 POST 메소드를 사용하는 것도 하나의 방법입니다.

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
• 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청 (정식스펙)

[ PUT 메소드 ]

PUT 메소드는 리소스가 있다면 완전히 대체하고, 리소스가 없다면 새롭게 생성해주는 메소드로 파일을 전송하기 위해서 사용됩니다. 리퀘스트 중에 포함된 엔티티를 리퀘스트 URI로 지정된 곳에 보존하도록 요구합니다. 우리가 알고있는 덮어쓰기랑 동작 방식이 같습니다.

• 리소스가 있으면 대체 없으면 생성 ( 완전히 대체 )
• PUT은 클라이언트가 리소스 위치를 알고 URI 를 지정한다.

[ PATCH 메소드 ]

PATCH 메소드는 리소스의 일부분만 교체하는 메소드입니다.

• 리소스 부분 변경

[ DELETE 메소드 ]

DELETE 메소드는 파일을 삭제하기 위해 사용합니다. PUT 메소드와는 반대로 동작하며 리쉐크트 URI로 지정된 리소스의 삭제를 요구합니다.

• 리소스 제거

[ HEAD 메소드 ]

HEAD 메소드는 GET과 같은 기능이지만 메시지 바디는 돌려주지 않습니다.

• 리소스 조회

[ OPTIONS 메소드 ]

OPTIONS 메소드는 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드를 조사하기 위해 사용합니다.

• 사용 가능한 메소드 조사

[ TRACE 메소드 ]

TRACE 메소드는 Web 서버에 접속해서 자신에게 통신을 되돌려 받는 루프백을 발생시킵니다. 리퀘스트를 보낼 때 "Max-Forwards" 라는 헤더 필드에 수치를 포함시켜 서버를 통과할 때마다 그 수치를 줄여갑니다. 클라이언트는 TRACE 메소드를 사용함으로써, 리퀘스트를 보낸 곳에 어떤 리퀘스트가 가공되어 있는지 등을 조사할 수 있습니다.

• 경로 추적

[ CONNECT 메소드 ]

CONNECT 메소드는 프록시에 터널 접속 확립을 요함으로써, TCP 통신을 터널링 시키기 위해서 사용됩니다.

• 프록시에의 터널링 요구

[ HTTP 메소드 속성 ]

- 안전 (Safe)

: 호출해도 리소스를 변경하지 않는 메소드를 안전하다고 한다. 계속 호출해서 장애가 나는 경우는 고려하지않고, 해당 리소스가 변하는지만 고려한다.

- 멱등 (Idempotent)

: 몇 번 호출하든 결과가 똑같은 메소드를 멱등하다고 한다. 서버가 정상 응답을 하지 못했을 때, 멱등한 메소드는 자동적으로 다시 호출하도록 복구 메커니즘을 만드는데 사용한다. 또, POST는 멱등이 아니다. 결제하는 경우를 생각해보면 POST는 2번 호출하면 중복 결제가 된다.

- 캐시가능 (Cacheable)

: 응답 결과 리소스를 캐시해서 사용해도 되는 메소드를 캐시가능하다고 한다.

참고

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

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

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

오늘은 가장 중요한 프로토콜인 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

문제 : www.acmicpc.net/problem/1747

에라토스테네스체

[ 알고리즘풀이 ]

 N에서 시작해 소수이면서 팰린드롬인 숫자를 찾을 때까지 N보다 크거나 같은 수를 순회한다. 

 1) 소수인지 체크

 : 에라토스테네스 체를 이용해 입력 최댓값인 100만 보다 넉넉히 큰 1000만까지 소수를 다 구해놓는다.

 --> 입력 최대값인 100만을 입력했을 때 정답이 100,3001 이므로 1000만까지 안 해도 됐었다...!!

 2) 팰린드롬인지 체크

 : 숫자의 각 자리를 추출해서 vector에 담아두고 팰린드롬인지 체크하면 된다.

[ 코드구현 C++ ]

[ github ]

github.com/travelbeeee/ProblemSolving/blob/master/BOJ/BOJ1747.cpp