728x90

HTTP /0.9 ~ /2 까지는 기본적으로 TCP를 사용

 

HTTP 버전별 특징

/0.9

<!-- Request -->
GET /mypage.html
<!-- Response-->
<HTML>
A very simple HTML page
</HTML>
  • GET 요청밖에 없음
  • HTML 파일자체만 응답으로 보내줄 수 있음

 

/1.0

<!-- Request -->

GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>
  • 버전, 상태코드, Content-Type 이 추가되고 HTML 파일들 이외에 다른 문서들을 전송할 수 있음

  • 1 Request & 1 Response Per Connection
    • 매번 새로운 연결로 성능저하
    • 서버 부하 비용 ↑

 

/1.1

  • 지정한 timeout 동안 커넥션을 닫지 않는 방식. 한 커넥션 동안 여려 요청과 응답이 발생할 수 있다.
  • 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내그 순서에 맞춰 응답을 받는 방식. 지연시간을 줄일 수 있다.
    • 첫번째 요청이 너무 길어지면 2번째 3번째 요청에 대한 응답 대기시간도 자동으로 길어진다.
  • Header 구조의 중복
    • http/1.1의 헤더에는 많은 메타정보들을 저장
    • 매 요청 시 마다 중복된 Header 값을 전송하게 되며 또한 해당 domain에 설정된 cookie 정보도 매 요청 시 마다 헤더에 포함되어 전송

/2

  • 기존 HTTP/1.x 버전의 성능향상에 초점을 맞춘 프로토콜
  • 표준의 대체가 아닌 확장
  • HTTP 메시지 전송 방식의 변화
    • 바이너리 프레이밍 계층 사용(새로 생김)
      • 메시지를 HEADER와 DATA 프레임으로 분할을 하고 이를 Binary로 인코딩한다. 
        • 파싱, 전송 속도 ↑, 오류 발생 가능성↓

Request and response multiplexing(다중화) -> Head Of Line Blocking 해결

임의의 프레임이 interleaving하여 끼어들기 가능

메시지간 순서라는것이 사라졌다.

 

Stream Prioritization -> 리소스간 우선순위를 설정 가능

Server Push -> 클라이언트가 요청하지도 않은 데이터를 서버가 알아서 Push해줌

html만 요청했는데 script.js와 style.css도 포함시켜줌

 

Header Compression (헤더 압축) -> 헤더의 크기를 줄여 페이지 로드 시간 감소

 

HTTP/1.1 HTTP/2
Persistent Connection HTTP 메시지 전송 방식의 변화
Pipelining 요청과 응답의 다중화
HTTP의 Head of Line Blocking 문제 리소스간 우선 순위 설정
Header 중복 문제 Server Push
  Header 압축
  TCP의 Heade of Line Blocking 문제

 

'HTTP' 카테고리의 다른 글

Basic HTTP Request/Response  (0) 2021.07.23
AJAX  (0) 2021.03.07
CSR vs SSR  (0) 2021.02.10
RESTful API 란?  (0) 2021.01.16
728x90
TCP : 전화와 유사 UDP : 라디오와 유사
일대일 연결만 가능 일대다 연결도 가능
손실되면 재전송 요청을 하므로 신뢰도가 높음 정보를 받았는지 확인치 않고 일방적으로 보냄
데어터의 순서와 무결성이 보장됨 데이터의 순서와 무결성을 보장하지 않음
속도가 상대적으로 느림 속도가 상대적으로 빠름
높은 신뢰도를 요하는 서비스에 적합 IPTV, 스트리밍 서비스에 적합

 

TCP Handshake

3 way handshake

3 way handshaking

연결할때는 3 way handshake를 이용해서 클라이언트와 서버가 총 3번 악수해서 연결이 잘되었다는 것을 확인한다.

 

4 way handshake

4 way handshaking

끊을 때는 4way handshake를 이용해서 끊겠습니다 -> 알겠습니다 -> 저도 끊겠습니다 -> 저도 알겠습니다 순서로  연결을 끊게 된다

 

HTTP (Hyper Text Transfer Protocol)

TCP/IP 위에서 전송하는 데이터의 규격에 대한 약속

 

HTTP의 특징

  • 단방향성 : 클라이언트가 서버에 요청을 보내고 이에 대한 응답을 받는 단방향적 통신 (서버가 클라이언트로 먼저 요청을 보낼 수 없다)
  • 비연결성 : 연결이 계속 유지되지 않고 요청에대한 응답이 끝나면 소켓을 끊는다 (소켓 통신과 반대되는 특징)
  • 무상태성 : 클라이언트가 서버와 연결된 상태가 아니기 때문에 기본적으로 상태를 가지지 않음. 이를 보완하기 위해 쿠키, 세션, 토큰을 사용함

 

HTTP Header의 구조

  • URL
  • HTTP 메소드
  • 응답 코드
  • IP 주소
  • 응답 헤더
    • contenth-length
    • date
    • server
  • 요청 헤더

https://velog.io/@sanspareilsmyn/6.-HTTP-Header

 

HTTP 캐시

응답의 헤더를 통해 컨텐츠 길이, 캐시의 유효시간, ETag를 전송한다.

 

캐시의 유효시간이 지나면 서버로부터 다시 읽어들이는데, 이 때 서버의 응답과 캐시로 가지고 있던 컨텐츠의 ETag가 같다면 업데이트하지 않는다.

 

'HTTP' 카테고리의 다른 글

HTTP 1.0 / 1.1 / 2  (0) 2021.07.23
AJAX  (0) 2021.03.07
CSR vs SSR  (0) 2021.02.10
RESTful API 란?  (0) 2021.01.16
728x90

ajax

ajax가 등장하기 전에는 웹 브라우저가 데이터를 요청하면 서버는 페이지에 대한 해당정보를 통째로 보내주게 되어 있었다.(html anchor tag) 이는 서버 및 클라이언트에 큰 부하를 일으키고 각 페이지 파일에 중복된 내용을 입력하게 만들었다.

그래서 이를 해결하고자 렌더링 후에도 비동기적으로 데이터를 요청하고
해당 정보를 바탕으로 url 변경없이 페이지의 일부만 수정할 수 있는 웹 개발 기법이 필요하게 되었다.

이를 AJAX라고 부르게 되었다.

AJAX의 특징은 다음과 같다.

  • 페이지 새로고침 없이 서버에 데이터 요청
  • 서버로부터 데이터를 받고 작업 수행

AJAX의 적용을 하고 있는 사례를 보고 싶으면 구글 연관검색어 서비스를 보면된다.

우리가 구글 검색창에 글자를 입력하면 서버에 현재 입력에 대한 연관검색어 요청과 응답을 받게 된다. 이동안 URL이 변경되거나 페이지가 새로고침 되는 현상은 없었다.

 

이제 AJAX를 도입함으로써 클라이언트, 서버의 부하를 줄일 수 있게되었고

변경사항에 대한 유지보수가 편리해졌다.(html파일들의 공통 요소를 모두 찾아 바꿀 필요가 없어졌기때문)

 

※ 그냥 html로 구현된 페이지가 서버한테 받은 데이터를 바탕으로 뷰 변경이 있을때

_ 새로고침과 URL 변경이 없다면 AJAX가 발생했다고 생각하자_

  • SPA(Single Page Application)는 AJAX를 활용하는 컨텐츠인가?

SPA는 index.html에 하나의 tag에 DOM manipulation을 할 수 있는 main.js를 matching 하여 페이지를 띄우는 기술이다.

이 SPA가 AJAX와 어떤 관계가 있는지 알아보자.

우리가 SPA을 구동할때 index.html을 실행한다. index.html은 다음과 같은 구조로 생겼다.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>simplex-execution-monitoring</title>
    <meta http-equiv="x-ua-compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="shortcut icon" href="/vue/assets/images/favicon.png" type="image/x-icon">
    <link rel="icon" href="/vue/assets/images/favicon.ico" type="image/x-icon">
    <link rel="stylesheet" href="//cdn.materialdesignicons.com/5.3.45/css/materialdesignicons.min.css">
  </head>
  <body>
    <div id="app"></div>
    <script src="/vue/dist/build.js"></script> // 번들파일
  </body>
</html>

우리는 bundle.js를 서버에 요청해 읽은 bundle.js를 바탕으로 <div id="app"></div>의 내용을 바꾼다. 이 때 이 요청으로 인해 페이지 새로고침이 일어나지않으며 URL변경도 발생하지 않는다.(만약 URL이 바꼈다면 mount 이후 route redirect 가 발생한 것이다)

 


 

XMLHttpRequest(XHR)

AJAX를 실현시켜주기 위해 만들어진 초창기 API이다.

이름과 다르게 XML뿐만 아니라 json을 비롯한 모든 종류의 데이터를 받아오는데 사용할 수 있다.

브라우저에서 기본적으로 제공해준다. stage가 low한 만큼 사용법이 까다롭다.

 

사용법은 다음과 같다.

var httpRequest;
if (window.XMLHttpRequest) {
  httpRequest = new XMLHttpRequest();
} else if (window.ActiveXObject) { // IE 6 이하
  httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
}

httpRequest.open('GET', 'http://www.example.org/some.file', true);
httpRequest.send(null);

httpRequest.onreadystatechange = function(){
  // 서버의 응답에 따른 로직을 여기에 작성합니다.
};
  • XML?

tag의 형식을 사용하여 데이터를 주고받을 수 있는 데이터 구조이다.

대표적인 XML형식을 사용하는 경우로 html 파일이 있다.

minify하여 enter없이 한줄로 전송된다.


 

jquery.ajax

XMLHttpRequest를 쓰다보니 쓰이지 않는 기능도 많고 사용법이 어려웠다.

그래서 이후에 등장한 것이 jquery.ajax 이다.

 

사용법은 다음과 같다.

$.ajax({
  url: 'http://localhost:3000/single-json',
  type: 'GET'
}).done((data, textStatus, jqXHR) => {
  console.log('성공');
}).fail((jqXHR, textStatus, errorThrown) => {
  console.log('실패');
}).always((param1, param2, param3) => {
  console.log('종료');
}).then((data, textStatus, jqXHR) => {
  console.log('성공 캐이스')
})

 


 

fetch

jquery.ajax() 이후에 등장하였다.

이제 jquery를 꼭 이용하지 않더라도 AJAX를 쉽게 구현 할 수 있게 되었다. 또한 구조는 비슷하지만 훨씬 간결해졌다.

jqeury.ajax()가 그러했듯이 최하단에서는 XMLHttpRequest를 사용한다.

 

XMLHttpRequest와 비교하여 fetch가 가지는 특징은 다음과 같다.

  • Promise 기반의 api이다.
  • 라이브러리를 import하지 않고도 사용할 수는 있지만(XHR과 동일) 지원하지않는 브라우저도 있다.
  • 전송된 요청에 대해서 취소할 수있는 기능이 없다(request aborting 불가)
  • timeout API가 존재하지 않는다.
  • 코드상에 then 이후에 catch가 있을 때 reject 시 then도 실행하고 catch도 실행한다.

사용법은 다음과 같다.

fetch('http://example.com/movies.json')
.then(function(response) {
  return response.json();
})
.then(function(myJson) {
  console.log(JSON.stringify(myJson));
});

 


 

axios

fetch가 가지고있지 않은 기능이 많아 이를 보완하는 api 이다.

axios가 가지는 특징은 다음과 같다.

  • Promise 기반의 api이다.
  • library를 import해야하지만 모든 브라우저에서 지원된다.
  • request aborting이 가능하다.
  • response로 받은 데이터는 json 형태로 자동 변환 된다.
  • 코드상에 then 이후에 catch가 있을 때 reject 시 catch만 실행한다.

사용법은 다음과 같다

let url = 'https://someurl.com';
let options = {
  method: 'POST',
  url: url,
  headers: {
    'Accept': 'application/json',
    'Content-Type': 'application/json;charset=UTF-8'
  },
  data: {
    property_one: value_one,
    property_two: value_two
  }
};
let response = await axios(options);
let responseOK = response && response.status === 200 && response.statusText === 'OK';
if (responseOK) {
  let data = await response.data;
  // do something with data
}

'HTTP' 카테고리의 다른 글

HTTP 1.0 / 1.1 / 2  (0) 2021.07.23
Basic HTTP Request/Response  (0) 2021.07.23
CSR vs SSR  (0) 2021.02.10
RESTful API 란?  (0) 2021.01.16
728x90

Web Application의 역사

1990년대 static site

  • 이미 잘 만들어진 html 문서를 서버가 가지고 있어 사용자가 해당 서버에 접속하면 서버에 배포되어있는 html 파일을 보여준다

아직 dynamic한 상황을 구현할 수 있는 JS가 등장하지 않아 <a>태그를 이용해 링크 버튼을 클릭하면 다른 html 파일을 불러와서 페이지를 업데이트한다. (MultiPageApplication)

매 링크마다 페이지 전체가 새로 로드된다는 점과 사용성이 떨어진다는 단점을 가지고 있다.

1996년 <iframe> 태그

  • 페이지의 각 화면 요소를 html파일로 Component화 시켜 부분적으로 받아와 업데이트 할 수 있다는 점이 바뀌었다.

문서내에서 또다른 문서를 가져올수 있는 iframe 태그가 도입되기 시작하였다.

아직 JS가 도입되지않아 html로만 이루어져있다는 점은 static site와 유사하지만 좀 더 복잡한 페이지를 쉽게 만들 수 있게 되었다. 하지만 아직 동적 페이지를 구성하는데 어려움이 남아 있었다.

1998년 XML HTTPRequest

  • XML HTTPRequest(흔히 우리가 아는 fetch)가 개발이 되어 html문서 전체가 아니라 JSON포맷으로 서버에서 필요한 데이터만 가져올 수 있게 되었다.

여기서부터 dynamic한 상황을 구현 할 수 있는 JavaScript와 비동기 통식방식인 XML HTTPRequest가 도입되었다..
비동기적으로 정보를 요청하고, 요청한 데이터를 바탕으로 동적으로 html요소를 생성해서 페이지에 업데이트할 수 있게 되었다.

const makeAJAXCall = (method,url,successCB, errorCB) =>{
  const xhr = new XMLHttpRequest;
  xhr.open(method,url,true);
  xhr.send();
  xhr.onload = (successCB,errorCB)=>{
    if(status >= 200 && status <=300){
      successCB();
      console.log('great');
    }else{
      errorCB();
      console.log('failed');
     }
  }
}

2005년

  • Single Page Application(SPA) 와 Client Side Rendering(CSR) 방식이 탄생하였다.

    SPA

    • 처음에는 빈 html파일을 서버로 부터 받아온 후 필요한 데이터를 서버로부터 가져와 html 파일을 해당 데이터로 업데이트 하는 방식이 도입되었다.

    CSR

    • SPA방식과 더불어 사용자 PC 성능이 좋아지고 JS도 표준화가 되어짐에따라 vueJS,react,angular와 같은 framework가 생김게 되었고 사용자 측에서 해당 페이지를 구성하는 CSR이 대두되었다.

CSR vs SSR

동적인 사이트를 다루게 되면서 렌더링 방식에 따라 CSR과 SSR로 나뉘게 된다. 각각의 특징에 대해 알아보도록 하자.

 

CSR

사용자 측에서 JS로 부터 받은 동적 정보를 바탕으로 페이지를 구성하는 방식이다.

CSR 작동 방식

순서

  1. 사이트 접속
  2. index 파일(html 파일)을 받아옴
  3. 링크되어있는 로직이 담겨있는 JS파일(app.js)을 요청함
  4. 해당 JS파일을 서버로부터받음
    • 이 app.js에는 vue,react,angular와 같은 framework도 있어 사이즈가 굉장히 크다
  5. 웹 페이지가 사용자에게 보여지게되고 클릭에 대한 반응(동적 반응)이 생김.
    • TTV 와 TTI가 동시에 가능하게됨

특징

  • 처음에 서버로 부터 받는 html파일에는 실제 사용자에게 보여질 id=root속성을 가진 tag와 어플리케이션에서 동적 상황에 필요한 app.js링크만 들어있다
  • 추가로 필요한 데이터는 서버로 요청해서 데이터를 받아d온다

단점

  • 첫화면을 보기까지 오래걸린다.
    • webpack과 같은 번들링툴을 이용해 분할하여 필수적인 요소부터 사용자에게 뿌리게한다.
  • SEO 가 좋지않다
    • 검색엔진이 html 기반으로 검색어를 추출하는데 CSR 웹 어플리케이션의 경우 빈 html파일로 구성되어있기 때문

SSR

static site 에서 영감받은 SSR이 탄생하였다. CSR에서 웹페이지 구성을 Client가 담당하였다면 SSR에서는 Server에서 웹페이지를 구성하여 html로 사용자에게 뿌려준다.

SSR 작동 방식

순서

  1. 사이트 접속
  2. 서버에서 js파일과 view 파일(ex. html)을 이용하여 index 파일(html)을 구성하여 사용자에게 보내준다
  3. 사용자는 해당 화면을 볼 수 있다(TTV)
  4. 동적으로 제어할수있는 JS파일(app.js)은 아직 못가져와 아직 동적 기능이 대입되지 않은 상태이다. 사용자는 이제 서버에게 JS파일을 요청한다.
  5. JS를 가져오면 동적 기능을 실행 할 수 있다.(TTI)

특징

  • 서버에서 필요한 데이터를 사용하여 html 파일을 만들어 사용자에게 보내고 html과 동적으로 제어하기위한 소스코드와 함께 가져온다

장점

  1. 페이지로드 빨라진다.
  2. 효율적인 SEO

단점

  1. 페이지를 구성하는 동적 정보가 바뀔때마다 빈 화면이 나타나는 blinking(flickering) 이슈
    •  
  2. 사용자가 몰리면 서버에 과부하가 걸리기쉽다
  3. 빠르게 웹페이지를 확인할수는 있지만(빠른 TTV) 동적으로 데이터를 처리하는 JS 를 늦게 받아와 반응을 없을경우가 있다.(느린 TTI)
    • TTV TTI의 갭을 줄이도록 매끄러운 UI 와 UX 를 제공하도록 한다.

SSG (static site generation)

  • react로 만든 webapplication을 정적으로 웹페이지를 생성해 미리 서버에 배포
    추가적으로 데이터를 가져오거나 동적으로 처리하는 로직이 있다면 JS를 받아오기때문에 처리가능함
  • react + gatsby, react + nextJS(원래 SSR지원)를 주로 사용한다

'HTTP' 카테고리의 다른 글

HTTP 1.0 / 1.1 / 2  (0) 2021.07.23
Basic HTTP Request/Response  (0) 2021.07.23
AJAX  (0) 2021.03.07
RESTful API 란?  (0) 2021.01.16
728x90

REST란?

  • Representational State Transfer 라는 용어의 약자로 웹에 존재하는 모든 resource(이미지,동영상,DB 자원)에 고유한 URI를 부여해 자원을 정의하고 자원에 대한 주소를 지정해 활용하는 방법론

RESTful API

  • REST 특징을 지키면서 API를 제공하는 것을 의미.(Coding Convention과 비슷)

REST API의 구성

개념 REST API
자원 URI( = endpoint)
행위 HTTP Method
표현 행위 + 자원
  • HTTP의도에 맞게 활용한다는 것
  • URI는 정보의 자원을 표현
  • 하나의 자원에 대한 행위는 HTTP Method(GET,POST,PUT,DELETE)로 표현. 
    • 하나의 endpoint로부터 서로 다른 요청을 4개까지 할 수 있다.
  • 표현은 이 둘의 조합으로 동사 목적어 처럼 사용하면 된다.
    • ex) DELTE localhost:3000/resources/myResource.jpg

REST의 특징

  1. Uniform Interface
    • HTTP 표준만 따른다면 모든 플랫폼(안드로이드/IOS)에서 언어나 기술에 종속되지 않고 사용가능하다.
  2. Stateless
    • HTTP의 특성을 이용하기 때문에 서버에서 어떤 작업을 하기위해 상태정보를 기억할 필요가 없고 들어온 요청에 대해서만 처리해주면 된다.
      • 상태정보란?
        • 이전에 무엇을 했고, 지금은 무엇을 했는지에 대한 정보. 예를들어 로그인 요청에 대한 AuthToken을 발급하는 Backend 서버의 경우, 상태 정보란 로그인 요청 이후의 해당 사용자의 로그인 이력과 AuthToken을 의미한다.
      • 웹 브라우저(클라이언트)의 요청에 대한 응답을 한 후, 해당 클라이언트와의 연결을 다음 요청이 올때까지 끊기 때문에 상태정보를 저장하지 못한다.
    • 상태정보(stateful) 유지를 위해 Cookie(client에 저장)와 Session(server에 저장) 기술을 사용한다.
  3.  Cacheable
    • HTTP라는 웹 표준을 사용하기 때문에 기본 브라우저에서 사용하는 인프라를 그대로 사용가능하다
  4.  Self-descriptiveness
    • Method + URI로 표현되어있어(body가 있다면 JSON형식) 메시지 포맷을 보고 직관적 이해가 가능하다.
  5. Client - Server 구조
    • Client는 유저와 관련된 처리를 서버는 REST api를 제공함으로써 각각의 역할이 확실하게 구분되고 일관적인 인터페이스로 분리되어 작동할 수 있게 한다.

'HTTP' 카테고리의 다른 글

HTTP 1.0 / 1.1 / 2  (0) 2021.07.23
Basic HTTP Request/Response  (0) 2021.07.23
AJAX  (0) 2021.03.07
CSR vs SSR  (0) 2021.02.10

+ Recent posts