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' 카테고리의 다른 글

AJAX  (0) 2021.03.07
CSR vs SSR  (0) 2021.02.10
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
CSR vs SSR  (0) 2021.02.10
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
AJAX  (0) 2021.03.07

+ Recent posts