[CS Study] 웹 개발 (Web Development)

HTTP Methods

HTTP Methods는 클라이언트가 웹 서버에 원하는 작업을 요청할 때 사용하는 동사입니다. 🌐

• GET: 리소스 조회. 서버의 데이터를 변경하지 않고 단순히 읽기만 할 때 사용합니다.
• POST: 리소스 생성/전송. 서버에 새로운 데이터를 생성하거나, 복잡한 데이터를 전송할 때 사용합니다.
• PUT: 리소스 전체 교체. 특정 리소스의 전체 내용을 클라이언트가 보낸 내용으로 덮어씁니다.
• DELETE: 리소스 삭제. 특정 리소스를 서버에서 삭제합니다.
• PATCH: 리소스 일부 수정. 리소스의 일부만 수정할 때 사용합니다. PUT과의 차이점은 리소스의 전체를 교체하는 것이 아니라, 특정 필드만 수정한다는 점입니다.
• HEAD: 리소스의 메타데이터를 얻기 위한 요청
• OPTIONS: 서버가 지원하는 메소드에 대한 정보를 얻기 위한 요청.
  • 어떤 메서드를 사용할 건지 물어보는 것.
  • 브라우저에서는 cor같은 걸 체크할 때 options를 날림.

GET 을 할 떄 물음표 뒤에 붙는 정보들. 쿼리 스트링. end. page size 기타 등등 이런 정보들이 필요함.

POST, PUT, PATCH는 페이로드. body에 담아서 보낸다.

---

HTTP Method의 멱등성(Idempotence)

동일한 요청 - 동일한 결과

멱등성은 HTTP 요청을 여러 번 반복해도 서버에 동일한 상태가 유지되는 특성입니다. 🔁

• 멱등성이 있는 메서드: GET, PUT, DELETE
  • GET: 같은 리소스를 여러 번 조회해도 데이터는 변하지 않습니다.
  • PUT: 특정 리소스를 여러 번 덮어써도 최종 상태는 동일합니다.
  • DELETE: 특정 리소스를 여러 번 삭제 요청해도, 첫 번째 요청으로 리소스가 삭제된 후에는 더 이상 삭제할 것이 없어 서버 상태에 변화가 없습니다.
• 멱등성이 없는 메서드: POST
  • POST: 같은 요청을 여러 번 보내면 리소스가 여러 번 생성될 수 있습니다. 예를 들어, 게시글 작성 요청을 두 번 보내면 게시글이 두 개 생성됩니다.
    • id 가 계속 바뀌기 때문에 동일한 결과를 보장할 수 없음.

patch는 멱등성을 보장할 수도 있고 아닐 떄도 있음.

• 일반적인 수정은 보장하지만, 조회수를 증가할 때는 값이 계속 바뀜.

---

HTTP 상태 코드 (Status Codes)

HTTP 상태 코드는 서버가 클라이언트의 요청을 처리한 결과를 숫자로 알려주는 3자리 코드입니다.

• 1xx (Informational): 요청을 받았으며 계속 진행해야 함을 나타냅니다. (예: 100 Continue)
• 2xx (Successful): 요청이 성공적으로 처리되었음을 나타냅니다. ✅ (예: 200 OK, 201 Created, 204 No Content)
  • 201; 새로운 리소스 생성
  • 202; accecpt. 데이터를 잘 받았을 때.
  • 204; 데이터가 없을 떄. 삭제했을 떄 동작된 데이터가 없다는 뜻. 삭제할 때 많ㅇ니 사용함
• 3xx (Redirection): 요청을 완료하기 위해 추가적인 작업이 필요함을 나타냅니다. ➡️ (예: 301 Moved Permanently, 304 Not Modified)
  • 서버의 상태가 바뀌었을 때
  • 301; 영구적으로 변경되었음. HTTP로 요청을 줬을 때 HTTPS로 301을 보냄.
• 4xx (Client Error): 클라이언트의 요청이 잘못되었음을 나타냅니다. 😥 (예: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found)
  • 클라이언트 오류
  • 400; 잘못된 요청. db 제한. 이메일 포맷. 등 .. 요청된 값이 이상할 떄. 필요한 값이 들어오지 않았을 때.
  • 401; 인증되지 않았을 때.
  • 403; 인증은 되었으나 권한이 없음.
  • 404; db 정보를 못찾을 때.
  • 405; 메서드를 허용하지 않음. options를 날렸을 때 지원하지 않은 메서드가 있는 경우.
  • 409; conflict. 클라이언트 요청이 현재 서버 상태와 맞지 않은 경우.
  • 429; too many request. 짧은 시간안에 과도한 요청.
• 5xx (Server Error): 서버가 요청을 처리하지 못했음을 나타냅니다. 💥 (예: 500 Internal Server Error, 503 Service Unavailable)
  • 서버 오류. 생기면 큰일나는 에러. 핸들링 되지 않는 에러.
  • 500; 일반적인 서버 에러.
  • 502; bad gateway. 클라이언트가 요청했을 때 일치하지 않을 때 많이 생김.
  • 503; service unavailable. 일시적으로 처리할 수 없을 떄. 서버 트래픽이 몰려서 동작 시간이 밀릴떄.

대표적인 상태코드는 상세히 외워야함.

---

GET/POST/PUT/DELETE 요청 실패 처리

요청이 실패했을 때는 적절한 HTTP 상태 코드를 반환하고, 클라이언트에게 실패 원인을 명확하게 알려줘야 합니다.

• GET 실패: 404 Not Found(리소스를 찾을 수 없을 때), 400 Bad Request(요청 매개변수가 잘못됐을 때), 500 Internal Server Error(서버 내부 오류) 등을 반환합니다.
• POST/PUT/DELETE 실패: 400 Bad Request(데이터 형식이 잘못됐을 때), 401 Unauthorized(인증되지 않은 사용자), 403 Forbidden(권한이 없을 때), 409 Conflict(데이터 충돌), 500 Internal Server Error 등을 반환합니다.

GET과 다른 메서드들은 요청을 여러번 보내도 멱등성을 보장하니까 상관없지만, POST는 중복된 요청을 받으면 바뀔 수 있으므로 idempotence key를 발급해서 이런 걸로 멱등성을 보장함.

• 점진적으로 시간을 늘리기도 함. (재시도 로직 중 하나)

클라이언트는 이 상태 코드를 기반으로 사용자에게 오류 메시지를 보여주거나, 재시도 로직을 구현하는 등 적절히 대응해야 합니다.

타임아웃이 발생했을 때

1. Retry logic: 요청이 실패한 경우 다시 재시도
2. Error handling: 적절한 에러 메시지를 사용자에게 제공하여 프로그램의 적절한 처리를 가능하게 함.
3. Timeout configuraton: 요청 타임아웃 시간을 늘리거나 줄이는 것이 가능
4. Network monitoring: 네트워크 상태를 주기적으로 모니터링하여, 타임아웃이 발생하는 경우에 미리 알아볼 수 있도록 함.
5. Fallback logic: 타임아웃이 발생하면 대처할 수 없느 경우, 대체 정보 또는 기본 정보를 제공함.

---

Connection Timeout과 Read Timeout

Connection Timeout과 Read Timeout은 네트워크 통신 시 발생할 수 있는 시간 초과 오류를 다룹니다.

• Connection Timeout: 클라이언트가 서버에 연결을 시도하는 시간에 대한 제한입니다. 🔗
  • 이 시간 안에 서버와 연결되지 않으면 타임아웃 오류가 발생합니다. (예: 서버가 다운되어 연결 요청을 받지 못할 때)
  • 연결 시간 초과: 서버와의 연결이 최대 연결 시간 초과 이내에 설정되지 않으면 요청 실패.
• Read Timeout: 서버와 연결은 되었지만, 응답 데이터 전체를 받는 데 걸리는 시간에 대한 제한입니다. ⏳
  • 서버가 요청을 처리하는 데 너무 오래 걸리거나 응답을 보내지 않을 때 발생합니다.
  • 읽기 시간 초과: 연결이 설정된 후 클라이언트가 서버로부터 응답을 최대 읽기 시간 초과 이내에 받지 않으면 요청 실패.

---

브라우저에 URL을 입력하면 어떤 일이 일어날까요?

1. URL 파싱: 브라우저가 입력된 URL을 프로토콜, 호스트, 포트, 경로 등으로 분석합니다.
2. DNS 조회: 브라우저가 DNS(Domain Name System) 서버에 접속하여 URL의 도메인(www.example.com)에 해당하는 IP 주소를 찾습니다. 🗺️
3. TCP/IP 연결: 찾은 IP 주소와 포트를 사용해 웹 서버와 TCP(Transmission Control Protocol) 연결을 수립합니다.
4. HTTP 요청: 연결이 수립되면, 브라우저가 서버에 HTTP 요청 메시지를 보냅니다.
5. HTTP 응답: 서버가 요청을 처리하고, 결과를 HTTP 응답 메시지에 담아 브라우저로 전송합니다.
6. 웹 페이지 렌더링: 브라우저는 받은 응답(HTML, CSS, JS 등)을 해석하여 화면에 웹 페이지를 그립니다. 🖥️

---

HTTP 요청 최적화 방법

HTTP 요청 최적화는 웹 페이지 로딩 속도를 높여 사용자 경험을 향상시키는 중요한 과정입니다.

• 리소스 압축: Gzip 같은 압축 기술을 사용해 HTML, CSS, JavaScript 파일의 크기를 줄입니다.
• 이미지 최적화: WebP와 같은 최신 포맷을 사용하거나, 이미지 크기를 줄여 로딩 시간을 단축합니다.
• 캐싱 활용: ETag, Cache-Control 헤더 등을 사용해 정적 리소스를 브라우저에 캐싱하여 다음 요청 시 서버에 다시 요청하지 않게 합니다.
• HTTP/2 또는 HTTP/3 사용: HTTP/1.1보다 효율적인 프로토콜을 사용해 다중 요청을 병렬로 처리하고 헤더 압축을 통해 성능을 높입니다.
• CDN(Content Delivery Network) 사용: 사용자와 가까운 서버에 정적 리소스를 분산 배치하여 로딩 지연을 줄입니다.

더 빠르게 하기 위한 기술들.

• gRPC. (데이터를 압축시키기 위해서 구글에서 사용하는..) 통신을 빠르게 하기 위해서..
  • restful 하지 않음.
  • HTTP 툴을 지원을 해서 훨씬 빠르다. json보다 빠르다.

---

웹 페이지 렌더링 과정 (SSR/CSR)

웹 페이지 렌더링은 서버나 클라이언트 중 어디에서 주로 처리하는지에 따라 SSR(Server-Side Rendering과 CSR(Client-Side Rendering로 나뉩니다.

• SSR (서버 사이드 렌더링): 서버에서 HTML, CSS, JS를 모두 처리하여 완성된 웹 페이지를 클라이언트에 전송합니다.
  • 장점: 초기 로딩 속도가 빠르고, SEO(검색 엔진 최적화)에 유리합니다.
  • 단점: 서버 부하가 커지고, 페이지 이동 시 전체 페이지를 다시 렌더링해야 해 UX가 좋지 않을 수 있습니다.
• CSR (클라이언트 사이드 렌더링): 서버는 빈 HTML 파일과 JavaScript 파일을 전송하고, 클라이언트(브라우저)가 JS를 다운로드하여 데이터를 가져와 페이지를 그립니다.
  • 장점: 페이지 이동 시 필요한 부분만 업데이트되어 빠르고, 서버 부하가 적습니다.
  • 단점: 초기 로딩 시간이 길고, SEO에 불리할 수 있습니다.

최근에는 SSG (Static Side Generation)이라는 기술을 사용함.

• 동적인건 서버에서, 정적인건 클라이언트에서.

브라우저 렌더링 과정

1. HTML 파싱: html 문서를 브라우저가 이해할 수 있는 구조로 파싱함.
2. CSS 파싱: CSS 스타일을 적용하기 위해 CSS 파일을 파싱함.
3. 렌더 트리 구성: HTML 요소를 구성하고, 스타일 정보를 트리 구조로 결합함.
4. 레이아웃 계산: 각 요소의 크기와 위치를 계산하여 렌더 트리에 적용함.
5. 페인틴: 각 요소의 배경, 테두리, 그림자 등을 그림.
6. 디스플레이: 브라우저가 렌더링한 결과를 사용자에게 보여줌.

---

REST API와 그 원칙

자원을 행위로 표현한다. 자원(URI) 를 행위(HTTP) 메서드로 표현(JSON, XML) 약속된 방식

REST API는 웹의 장점을 최대한 활용하는 아키텍처 스타일로, 자원을 URI(Uniform Resource Identifier로 표현하고 HTTP 메서드를 사용해 해당 자원에 대한 작업을 수행합니다.

웹 상의 어플리케이션을 개발할 떄, 다른 어플리케이션과 데이터를 교환할 수 있도록 HTTP 프로토콜을 기반으로 한 아키텍처 스타일.

+언어와 플랫폼의 제약x, HTTP 프로토콜의 장단점 활용 -보안 취약. 데이터의 유효성 검증 등의 처리가 추가적으로 필요함.

---

SOAP와 RESTful API의 차이점

웹 서비스 아키텍처 스타일의 두 가지 주요 타입.

특징 SOAP (Simple Object Access Protocol) RESTful API (Representational State Transfer)

프로토콜	프로토콜, 엄격한 표준	아키텍처 스타일, 느슨한 규약
데이터 형식	XML만 사용	JSON, XML 등 다양한 형식 사용
전송 방식	HTTP, SMTP 등 다양한 프로토콜 사용	HTTP만 사용
무게	무겁고 복잡함	가볍고 단순함
사용 사례	보안이 중요한 엔터프라이즈 환경	대부분의 웹/모바일 서비스

SOAP은 보안, 확장성, 멀티 언어 지원 but 높은 부하, 복잡성

• 확장성; 여러 프로토콜에서 사용할 수 있음.

RESTful은 경량, 간결성, 쉬운 구현 but, 제한적인 보안, 상태 관리 어려움.

• 구현 자유도.

---

API Gateway

API Gateway는 클라이언트 요청을 여러 마이크로서비스로 라우팅하고, 인증, 로깅, 모니터링 등의 공통 기능을 처리하는 단일 진입점입니다. 🚪

주요 사용 이유:

• 단일 진입점: 클라이언트는 여러 백엔드 서비스가 아닌 API Gateway에만 요청하면 되므로, 복잡도가 줄어듭니다.
• 공통 기능 처리: 인증/인가, 로깅, 모니터링, 속도 제한 등 모든 요청에 공통으로 적용되는 기능을 게이트웨이에서 처리할 수 있습니다.
• 로드 밸런싱: 요청을 여러 서비스 인스턴스로 분산시켜 부하를 조절합니다.
• 마이크로서비스 보호: 백엔드 서비스의 상세한 구조를 외부에 노출시키지 않고, 보안을 강화할 수 있습니다.

애플리케이션 개발자가 서비스를 제공할 수 있도록 다양한 애플리케이션에 대한 요청을 수집하고, 이를 적절한 백엔드 서비스로 전달하는 역할.

• 보안, 로드 밸런싱, 모니터링, 캐시, 라우팅 등의 기능을 포함.
• 애플리케이션의 효율적인 운영 및 관리 지원.

ex. 네이버를 사용할 때 네이버지도 등 다양한 게 있는데 한 번에 진입할 수 있다는 것. (1. 단일진입점)

인증/ 인가를 한 번에 처리할 수 있다는 것.

로드 밸런싱을 해줄 수 있다.

• 속도를 위해서 사용하는 것은 아님. 보안과 관리를 위해서 사용.

---

세션 기반 인증과 토큰 기반 인증(JWT)의 차이점

특징 세션 기반 인증 토큰 기반 인증 (JWT)

상태 저장	서버가 사용자 상태(세션)를 저장	서버는 상태를 저장하지 않음 (무상태)
확장성	수평 확장 시 세션 동기화 문제 발생	무상태이므로 수평 확장 용이
데이터 저장 위치	서버 메모리 또는 DB	클라이언트(브라우저, 앱)
보안	CSRF 공격에 취약할 수 있음	토큰 탈취 시 위험, HTTPS 필수

---

JWT (Json Web Token) **

JWT는 정보를 안전하게 주고받기 위해 사용하는 토큰 기반 인증 방식입니다. 📄

구조: JWT는 세 부분으로 나뉘며, 각 부분을 . 으로 구분합니다.

1. 헤더(Header): 토큰의 타입(JWT)과 서명에 사용된 알고리즘(HS256, RS256 등)을 포함합니다.
2. 페이로드(Payload): 클레임(Claim)이라고 부르는 실제 정보(사용자 ID, 만료 시간 등)를 포함합니다.

ID, 만료시간, ISS (토큰을 어디서 발급 받았는지), 토큰 발급 시간도 있음.

• 토큰이 너무 빨리 만료되면? refresh token

1. 서명(Signature): 헤더와 페이로드를 비밀 키(Secret Key)로 암호화한 값으로, 토큰의 위변조 여부를 검증하는 데 사용됩니다.

• jwt.io에 들어가면 정보가 다 나옴.
• 왜 쓸까? stateless 를 보장하기 위해서 사용함.
• 토큰을 위조할 수 없음.

동작 방식:

1. 사용자가 로그인 요청을 하면, 서버는 사용자 정보를 담은 JWT를 생성합니다.
2. 서버는 JWT를 클라이언트에게 전달하고, 클라이언트는 이를 로컬 저장소에 보관합니다.
3. 이후 클라이언트가 서버에 요청을 보낼 때, 헤더에 JWT를 담아 함께 보냅니다.
4. 서버는 요청을 받을 때마다 JWT의 서명을 검증하고, 유효한 토큰이면 페이로드에 있는 정보를 사용하여 요청을 처리합니다.

REST API를 구축할 때 사용하는 인증 기술

+간단한 구조: JWT는 JSON 객체로 구성되어 있기 때문에 간단하게 구현할 수 있음.

+분산 환경에서의 사용: JWT는 서버와 클라이언트 간에 분산 환경에서도 사용 가능.

+다중 언어 지원: JWT는 JSON 객체로 구성되어 있기 때문에 다중 언어에서 지원 가능.

• 보안 문제: JWT는 암호화되지 않은 데이터를 포함. 고정 크기 데이터: JWT의 크기가 고정되어 있기 때문에 많은 양의 데이터를 포함하려면 복잡한 방법을 사용.

---

서버리스 (Serverless) 아키텍처

서버리스는 서버를 직접 관리하지 않고, 클라우드 공급자(AWS, Google Cloud 등가 서버를 대신 관리하는 컴퓨팅 모델입니다. ☁️ 개발자는 코드만 작성하고 배포하면, 서버의 인프라 관리, 확장, 운영은 모두 클라우드 공급자가 담당합니다.

• 주요 특징:
  • 이벤트 기반: 특정 이벤트(HTTP 요청, DB 변경 등)가 발생할 때만 함수가 실행됩니다.
  • 자동 확장: 요청량에 따라 자동으로 인스턴스가 확장되거나 축소됩니다.
  • 종량제: 사용한 만큼만 비용을 지불합니다.

---

게시판 CRUD 기능 구현

CRUD는 Create(생성), Read(읽기), Update(수정), Delete(삭제를 의미하며, 게시판 기능의 핵심입니다.

• Create (게시글 작성): POST /api/posts
  • 클라이언트: 게시글 제목, 내용을 JSON 형태로 서버에 보냅니다.
  • 서버: 받은 데이터를 검증하고, DB에 새로운 게시글 레코드를 생성합니다. 성공 시 201 Created를 반환합니다.
• Read (게시글 목록/상세 조회): GET /api/posts (목록), GET /api/posts/{id} (상세)
  • 클라이언트: 특정 게시글 ID 또는 목록 조회를 요청합니다.
  • 서버: DB에서 해당 데이터를 조회하여 클라이언트에 JSON 형태로 응답합니다. 성공 시 200 OK를 반환합니다.
• Update (게시글 수정): PUT /api/posts/{id}
  • 클라이언트: 수정할 게시글 ID와 수정된 내용을 JSON 형태로 보냅니다.
  • 서버: DB에서 해당 게시글을 찾아 내용을 덮어씁니다. 성공 시 200 OK를 반환합니다.
• Delete (게시글 삭제): DELETE /api/posts/{id}
  • 클라이언트: 삭제할 게시글의 ID를 보냅니다.
  • 서버: DB에서 해당 게시글을 삭제합니다. 성공 시 204 No Content를 반환합니다.

다수와 CRUD하는 경우

• 데이터베이스 캐시 적용, 로드 밸런싱, 분산 데이터베이스 구축, 트랜잭션 관리, API 요청 한도 제한 구현.

---

게시판 댓글 기능 구현

댓글 기능은 게시글에 종속되는 하위 리소스로 구현합니다.

• 댓글 작성: POST /api/posts/{postId}/comments
  • 클라이언트: 댓글을 달 게시글 ID와 댓글 내용, 작성자 정보를 보냅니다.
  • 서버: DB의 comments 테이블에 게시글 ID와 함께 댓글 레코드를 생성합니다.
• 댓글 조회: GET /api/posts/{postId}/comments
  • 클라이언트: 특정 게시글의 ID로 댓글 목록을 요청합니다.
  • 서버: comments 테이블에서 해당 게시글 ID에 해당하는 모든 댓글을 찾아 반환합니다.
• 댓글 수정: PUT /api/comments/{commentId}
• 댓글 삭제: DELETE /api/comments/{commentId}
• 대댓글 구현: comments 테이블에 부모 댓글 ID(parent_id)를 저장하는 필드를 추가하여 계층 구조를 만듭니다.

직접 구현해보기: 대댓글을 어떻게 만들까?

• 게시글: 게시글 id, 작성자 id, 게시글 내용
• 댓글: 게시글 id, 댓글 id, 댓글 작성자 id, 댓글 내용
• 대댓글: 게시글 id, 댓글 id, 대댓글 작성자 id, 대댓글 id, 대댓글 내용.

inheritance

• parent id 를 연속된 값으로 string으로 받아오는 방식...
• https://limvik.github.io/posts/how-to-store-tree-structure-in-database/
• -- 오늘은 여기까지 ---
• 다음주에는 웹소켓에 집중
• 다음주는 백엔드..

LRU (Least Recently Used) 캐시 알고리즘

LRU는 가장 오랫동안 사용되지 않은 데이터를 캐시에서 삭제하는 알고리즘입니다. 🗑️

작동 방식:

1. 캐시에 데이터가 추가되거나 조회되면, 해당 데이터는 가장 최근에 사용된 데이터가 됩니다.
2. 캐시 공간이 부족해지면, 가장 오랫동안 사용되지 않은(Least Recently Used) 데이터를 제거하고 새로운 데이터를 추가합니다.
3. 이 알고리즘은 링크드 리스트(Doubly Linked List와 해시맵(HashMap을 조합하여 효율적으로 구현됩니다. 해시맵으로 O(1) 시간에 데이터를 찾고, 링크드 리스트로 사용 순서를 관리합니다.

---

웹소켓 (WebSocket)

웹소켓은 클라이언트와 서버 간에 지속적인 양방향 통신 채널을 제공하는 프로토콜입니다. 🔄

HTTP는 요청과 응답이 한 번씩 이루어지는 단방향 통신인 반면, 웹소켓은 한 번 연결되면 클라이언트와 서버가 자유롭게 데이터를 주고받을 수 있습니다.

• 사용 예시: 실시간 채팅, 실시간 주식 차트, 온라인 게임 등

서버에서 클라이언트, 클라이언트에서 서버로 데이터를 실시간으로 전송.

즉각적인 상호작용이 가능한 웹 애플리케이션 개발에 적합함.

---

웹소켓과 일반 소켓(Socket) 통신 차이점

• 웹소켓: HTTP 프로토콜 위에서 동작합니다. HTTP 핸드셰이크를 통해 연결을 수립한 후 웹소켓 프로토콜로 전환됩니다. 브라우저에서 기본적으로 지원하므로 웹 환경에서 사용이 용이합니다.
• 일반 소켓: TCP/IP 소켓을 직접 사용합니다. OS의 API를 이용해 소켓을 생성하고 관리해야 하며, 브라우저에서는 사용할 수 없습니다. 일반적인 클라이언트-서버 애플리케이션(네트워크 게임, 파일 전송 프로그램 등)에서 사용됩니다.

---

RTMP (Real-Time Messaging Protocol)

RTMP는 어도비(Adobe)에서 개발한 실시간 스트리밍 전송 프로토콜입니다. 🎥

주로 서버에서 클라이언트로 오디오, 비디오, 데이터를 전송하는 데 사용됩니다. 최근에는 HTTP 기반의 HLS, MPEG-DASH 등의 프로토콜이 더 널리 사용되고 있지만, 여전히 라이브 방송 분야에서 많이 활용되고 있습니다.

미디어 스트리밍을 위한 프로토콜

• 비디오, 오디오, 메타데이터를 가속된 속도로 전송
• 멀티 미디어 컨텐츠를 실시간으로 전송함.
• 전송 구조, 연결 관리, 컨트롤 메시지, 스트리밍 메시지, 플래시 메모리 관리 등의 부분으로 구성되어 있음.