[HTTP] URI와 웹 브라우저 요청 흐름 (URL, HTTP)

 

 

URI ❓ URN ❓ URL ❓

 

URI(Uniform : 리소스 식별하는 통일된 방식 Resource : 자원, URI로 식별할 수 있는 모든 것(제한이 없음) Identifier : 다른 항목과 구분하는데 필요한 정보 )

URI는 인터넷에서 특정 리소스를 고유하게 식별하고 위치를 지정하는 문자열의 형식입니다. URI는 로케이터(locater), 이름(name) 또는 둘 다 추가로 분류될 수 있습니다. URI는 주로 웹에서 URL(Uniform Resource Locator)과 URN(Uniform Resource Name)의 개념으로 사용됩니다.

식별한다는 것은 주민번호를 식별할 수 있듯이 자원 자체를 식별하는 방법입니다. 해당 방법에는 URL, URN이 있는데 URL은 리소스가 있는 위치를 지정 , URN은 리소스에 이름을 부여해주는 것을 말합니다. 웹 브라우저에서 도메인으로 접속하기위해 적는 것은 URL을 말하며, 위치는 변할 수 있지만 이름은 변하지 않습니다. URN의 이름만으로 실제 리소스를 찾을 수 있은 방법이 보편화 되어있지 않습니다.

• URL의 전체 문법 - scheme(스키마)://[userinfo@]host[:port][/path][?query][#fragment]URL 스키마는 주로 프로토콜을 사용하며 프로토콜은 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙 ( ex. http, https, ftp 등)
• example : **https://www.google.com: 443 /search ?q=hello&hI=ko**

1. 프로토콜(Protocol): 리소스에 접근하기 위해 사용되는 프로토콜을 나타냅니다. 예를 들어, "http://" 또는 "ftp://" 등이 프로토콜을 나타냅니다.
2. 호스트(Host): 리소스가 위치한 서버의 도메인 이름이나 IP 주소를 나타냅니다. 예를 들어, "[www.example.com"이](http://www.example.㯘%22-ub50a/) 호스트입니다.
3. 포트(Port): 리소스에 접근하기 위해 사용되는 포트 번호를 나타냅니다. 예를 들어, "[https://www.example.com:443"에서](https://www.example.com:443%22%EC%97%90%EC%84%9C/) 443은 포트 번호입니다. http는 80포트 https는 443포트를 주로 사용, 포트는 생략이 가능합니다.
4. 경로(Path): 리소스의 위치나 계층 구조를 나타내는 경로를 나타냅니다. 예를 들어, "/index.html"이 경로입니다.
5. 쿼리(Query): key=value의 형태이고 ?로 시작, &로 추가가 가능합니다. 추가적인 매개변수나 데이터를 전달하기 위해 사용되는 쿼리 문자열을 나타냅니다. query parameter, query string 등으로 불리며 웹 서버에 제공하는 파라미터 문자형태입니다. 예를 들어, "?id=12345"와 같은 형식으로 사용됩니다.

웹 브라우저가 URL을 입력하여 서버로 보내면 google 서버를 찾기 위해 DNS 서버를 조회하여 IP주소를 알게 됩니다. IP와 port를 알아낸 후 GET/serarch?q=hello%hi=ko HTTP/1.1 Host: www.google.com을 작성하여 HTTP 요청 메세지를 보내게 됩니다.

1. 클라이언트 요청:
   • 클라이언트는 HTTP 프로토콜을 사용하여 서버에 요청을 보냅니다. 요청은 클라이언트가 수행하려는 작업을 나타내며, 주로 HTTP 메소드(GET, POST, PUT, DELETE 등)와 요청 URI(Uniform Resource Identifier)를 포함합니다.필요에 따라 헤더(Header)에 추가적인 정보를 포함할 수 있습니다.
2. 서버 응답:
   • 서버는 클라이언트의 요청을 받고 처리한 후, 서버도 똑같이 HTTP 응답 메시지를 생성하여 클라이언트에게 전송합니다. 응답은 요청에 대한 처리 결과를 포함하며, 주로 상태 코드(예: 200 OK, 404 Not Found)와 응답 본문을 포함합니다. 헤더에도 추가적인 정보(예: 캐시 제어, 쿠키)를 포함할 수 있습니다.
3. 데이터 전송:
   • 클라이언트와 서버 간에 데이터는 TCP/IP 기반의 연결을 통해 전송됩니다. 데이터는 요청과 응답의 본문에 포함되며, 일반적으로 텍스트나 이진 형식으로 전송됩니다. 전송 중에는 데이터의 무결성과 신뢰성을 위해 TCP 프로토콜이 패킷을 분할하고 재조립하며, 오류 검사와 재전송을 수행합니다.
4. 연결 종료:
   • 데이터 전송이 완료되면 클라이언트나 서버는 연결을 종료합니다. 일부 경우(예: 지속적인 연결)에는 연결을 유지하고 추가적인 요청과 응답을 주고받을 수도 있습니다.

 

💡 모든 것이 HTTP

HTTP(Hypertext Transfer Protocol)는 인터넷에서 웹 페이지를 전송하는 데 사용되는 프로토콜입니다. HTTP는 클라이언트와 서버 간의 통신을 위한 규약으로, 클라이언트가 웹 서버에 요청을 보내고, 서버가 클라이언트에게 요청한 리소스(웹 페이지, 이미지, 동영상 등)를 제공하는 방식으로 동작합니다.

프로토콜이란 ? 서로간의 통신을 위한 약속, 규칙 / 주고 받을 데이터에 대한 형식을 정의한 것

클라이언트와 서버간의 소통을 위해서 미리 정해놓은 것입니다. 실생활에서 예를 들면, 편지를 보낼 때 받는 사람 , 주소, 날짜 등 정해진 형식이 있고, 편지봉투에도 보내는 사람 주소 받는 사람등의 작성의 사회적 합의로 편하게 사용이 가능합니다.

HTTP(Hyper Text Transfer Protocol)이란? 텍스트 기반의 프로토콜을 말합니다. 단순하고 읽기가 쉬우며, Human readable이라고도 합니다. HTTP의 큰 특징은 상태를 유지하지 않는 stateless 인데 , 클라이언트의 정보를 저장하지 않습니다. 같은 클라이언트가 요청을 2번 하더라도 서버는 구분하지 못합니다. 이런 점을 보완하기 위해 쿠키와 세션을 사용합니다. 확장이 가능한 특징도 있습니다. 커스텀 헤더(header)를 추가할 수 있는 기능이 있습니다. HTTP의 헤더는 헤더이름 : 값이 적힌 문장으로 적혀있으며, 헤더 이름은 대소문자를 구분하지 않아도 됩니다. 표준에 정해놓지 않는 헤더를 커스텀 헤더라고 하며, 서버와 클라이언트간에 서로 약속만 되어있다면 헤더의 사항들을 추가할 수 있습니다.

HTTP/1.1 1997 : 가장 많이 사용하고 우리에게 가장 중요한 버전

HTTP는 애플리케이션 계층(Application Layer)에서 작동하는 프로토콜로, TCP/IP 프로토콜 스택 위에서 동작합니다. HTTP는 클라이언트와 서버 사이에 상태를 유지하지 않는 비상태(Stateless) 프로토콜로, 각 요청은 독립적으로 처리되며 이전 요청과의 관계를 유지하지 않습니다. 이러한 특징으로 인해 HTTP는 간단하고 확장성이 높은 프로토콜로 널리 사용되고 있습니다.

HTTP는 주로 웹 브라우저와 웹 서버 간의 통신에 사용되며, 클라이언트가 웹 페이지를 요청할 때는 HTTP 요청 메서드(GET, POST, PUT, DELETE 등)를 사용하여 서버에 요청을 전송합니다. 서버는 해당 요청을 처리하고 요청한 리소스를 HTTP 응답으로 반환합니다. HTTP 응답은 상태 코드(200 OK, 404 Not Found 등)와 함께 클라이언트에게 전달되며, 클라이언트는 이를 받아 웹 페이지를 표시하거나 필요한 동작을 수행합니다.

 

📋 HTTP의 특징

1. ‘클라이언트 서버 구조’
   Request-Response(요청-응답)는 클라이언트-서버 모델에서 가장 기본적인 통신 패턴입니다. 클라이언트가 서버에게 요청을 보내면, 서버는 해당 요청을 처리하고 클라이언트에게 응답을 반환합니다. 이러한 요청과 응답은 네트워크를 통해 이루어지며, 다양한 프로토콜과 방식으로 구현될 수 있습니다.
   클라이언트 서버 구조 개념적으로 분리를 한 후 비즈니스 로직, 데이터의 경우 전부 서버에 보관하고 클라이언트는 사용성, UI등에 집중합니다. 
   
   
   • 클라이언트는 서버에게 특정 동작을 수행하거나 원하는 정보를 요청하기 위해 요청 메시지를 생성하고 전송합니다. 서버는 클라이언트로부터 받은 요청을 처리하고, 요청에 따라 필요한 동작을 수행합니다. 서버는 요청을 분석하여 필요한 데이터를 검색하거나 처리하고, 그 결과를 응답 메시지에 담아 클라이언트에게 전송합니다.
   • Request-Response 패턴은 웹을 비롯한 다양한 분야에서 사용되는 통신 방식입니다. 웹 브라우저가 웹 서버에 웹 페이지를 요청하고, 서버는 해당 페이지를 제공하는 과정이 Request-Response 패턴으로 이루어집니다. 이 외에도 API 호출, 데이터 요청, 파일 전송 등 다양한 상황에서 클라이언트가 서버에게 요청을 보내고, 서버는 해당 요청을 처리하여 응답을 반환합니다.
     
     
2. ‘무상태 프로토콜 ( Stateless)’
   HTTP (Hypertext Transfer Protocol)는 무상태(Stateless) 프로토콜입니다. 이는 HTTP 서버와 클라이언트 간의 통신에서 상태 정보를 유지하지 않는다는 의미입니다. 각각의 클라이언트 요청은 독립적으로 처리되며, 이전 요청과의 관련성이나 의존성이 없습니다.
   
   상태 유지 - Stateful 중간에 상태가 바뀔 경우 이전의 상태정보를 미리 알려줘야합니다. 클라이언트가 하나의 서버에게 오쳥하면 상태를 유지하게 되는데, 에러가 발생하면 클라이언트는 다시 처음부터 요청을 해야합니다.
   
   상태 정보의 저장 없음: 서버는 클라이언트의 상태 정보를 저장하지 않습니다. 이로 인해 서버 측에서 클라이언트 상태를 유지하거나 추적할 필요가 없어집니다. / scale out - 수평적 확장이 가능합니다.
   
   

 

• 확장성과 부하 분산: 갑작스레 클라이언트의 요청이 증가하더라도 stateless 상태라면 서버의 대거 투입이 가능합니다. 응답 서버를 쉽게 바뀔 수 있습니다. 서버는 클라이언트의 상태를 유지하지 않기 때문에, 많은 수의 클라이언트 요청을 동시에 처리하는 확장성이 높아집니다. 또한, 여러 서버로 부하를 분산시킬 수 있어 대규모 시스템에서 효율적인 분산 처리가 가능합니다.
• 클라이언트-서버 분리: 상태 정보를 유지하지 않는 HTTP는 클라이언트와 서버 간의 분리를 강조합니다. 서버는 단순히 클라이언트의 요청을 받아 처리하고, 클라이언트는 필요한 상태 정보를 요청에 포함하여 전달합니다. 이를 통해 서버와 클라이언트의 독립성과 유연성이 증가합니다.
• 자유로운 요청 처리: 무상태 프로토콜은 클라이언트의 요청에 대해 서버가 즉시 응답을 반환하고 연결을 끊을 수 있습니다. 이로 인해 서버의 리소스를 효율적으로 사용할 수 있습니다.

 

무상태 프로토콜의 한계는 상태가 유지한 경우입니다. 예를 들어, 로그인 세션을 유지하거나 (로그인한 사용자의 경우 로그인 한 상태를 서버에 유지 등 ) 상태 정보에 기반한 작업을 수행하는 경우에는 별도의 메커니즘이 필요합니다. 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 꼭 필요한 경우에만 최소한의 상태를 유지하여 사용합니다