반응형

2017/09/18 - [PHP] - [PHP] DB에서 특정 행들만 가져오기(7) - DB에서 가져온 정보 출력하기 mysqli_fetch_row()에서 본 대로

 

mysqli_fetch_row() 는 다음과 같이 배열의 번호로 요소를 출력할 수 있다.

 

 

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title></title> </head> <body> <?php $query = "SELECT * FROM user_data"; $result = mysqli_query($conn, $query); $row = mysqli_fetch_row($result); echo "<TABLE BORDER=1><TR>", "<TD>",$row[0],"</TD>", "<TD>",$row[1],"</TD>", "<TD>",$row[2],"</TD>", "<TD>",$row[3],"</TD>", "</TR></TABLE>" ?> </body> </html>

 

 

 

 

mysqli_fetch_assoc() 의 assoc은 연관배열associative array 의 약자로,

 

다음과 같이 필드명(열이름, 키값)을 통해 데이터를 호출할 수 있다.

 

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title></title> </head> <body> <?php $query = "SELECT * FROM user_data"; $result = mysqli_query($conn, $query); $row = mysqli_fetch_assoc($result); echo "<TABLE BORDER=1><TR>", "<TD>",$row['log_num'],"</TD>", "<TD>",$row['user_id'],"</TD>", "<TD>",$row['date'],"</TD>", "<TD>",$row['product'],"</TD>", "</TR></TABLE>" ?> </body> </html>

 

 

 

mysqli_fetch_array() 는 두 방식 모두 사용할 수 있다.

 

즉 키값과 번호 중 아무 것이나 사용해도 무방하다.

 

 

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title></title> </head> <body> <?php $query = "SELECT * FROM user_data"; $result = mysqli_query($conn, $query); $row = mysqli_fetch_array($result); echo "<TABLE BORDER=1><TR>", "<TD>",$row[0],"</TD>", "<TD>",$row['user_id'],"</TD>", "<TD>",$row['date'],"</TD>", "<TD>",$row[2],"</TD>", "</TR></TABLE>" ?> </body> </html>

 

 

 

다만 주의할 것이, mysqli_fetch_array 이 담고 있는 요소의 수는 원래 배열의 두 배가 될 수 있다.

 

다음과 같이 mysqli_fetch_row 와 mysqli_fetch_array 각각의 배열을 출력하라고 명령(print_r) 해 보자.

 

 

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title></title> </head> <body> <?php $query = "SELECT * FROM user_data"; $result = mysqli_query($conn, $query); $row = mysqli_fetch_row($result); $result = mysqli_query($conn, $query); $arr = mysqli_fetch_array($result); print_r($row); echo "</br>"; print_r($arr); ?> </body> </html>

 

 

 

mysqli_fetch_row 는 필드명(키값)이 0, 1, 2, 3 이지만,

 

mysqli_fetch_array 는 필드명이 0, log_num, 1, user_id, 2, product, 3, date 와 같이 매겨져 있다.

 

 

표로 표현하면 다음과 같다.

 

 

 

 

그래서 mysqli_fetch_array()는 필드명과 번호로 둘 다 호출할 수 있는 것이다.

 

 

이렇게 요소의 수가 다른 것은 다음과 같이 while() 을 쓴다면 문제가 될 수 있다.

 

mysqli_fetch_row 는 요소의 개수가 4개이므로 count($row)를 사용하면 다음과 같이 결과가 나오지만

 

 

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title></title> </head> <body> <?php $query = "SELECT * FROM user_data"; $result = mysqli_query($conn, $query); $row = mysqli_fetch_row($result); $i = 0; echo "<TABLE border=1><TR>"; while($i<count($row)){ echo "<TD>",$row[$i],"</TD>"; $i = $i + 1; } echo "</TR></TABLE>"; ?> </body> </html>

 

 

 

mysqli_fetch_array 는 count($row) 를 사용할 경우 결과는 다음과 같다.

 

 

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title></title> </head> <body> <?php $query = "SELECT * FROM user_data"; $result = mysqli_query($conn, $query); $row = mysqli_fetch_array($result); $i = 0; echo "<TABLE border=1><TR>"; while($i<count($row)){ echo "<TD>",$row[$i],"</TD>"; $i = $i + 1; } echo "</TR></TABLE>"; ?> </body> </html>

 

 

count($row) 는 4가 아니라 8이며,

 

while() 은 row[0] 부터 row[3] 까지는 값을 출력하다가 row[4] 부터 row[7] 까지는 에러를 출력하게 된다.

 

 

 

 

출처 : lightblog.tistory.com/117

반응형
반응형

Model1 아키텍쳐

-      클라이언트가 jsp 요청

-      jsp 에서 View 단의 html  css 를 처리하고 Controller 단의 사용자 입력정보추출, DB연동처리, 화면 네비게이션 등의 기능을 처리한다.

-      jsp 에서는 자바빈즈를 이용해 비즈니스 로직인 Model 에 접근한다.

-      그 다음으로 DB 연동을 통해 사용자가 요청한 정보를 가져온다.

-      요청에 대한 응답으로 통신을 마친다.

-      이 구조의 특징은 jsp 에서 Controller 기능과 View 기능을 모두 제공한다는 것이다. 이로 인해서 jsp 파일에 자바 코드와 디자인 소스들이 혼재하기 때문에 유지보수에 어려움이 따른다.

 

Model2 아키텍쳐

-      클라이언트가 jsp 를 요청

-      Controller 단의 Servlet 은 브라우저의 요청에 대해 어떤 자바빈즈가 실행되어야 하는지, 어떤 jsp 가 실행 되어야 하는지를 제어한다.

-      Servlet 은 자바빈즈를 이용해 Model 단에서 비즈니스 로직을 수행하고 그 결과를 View 단인 jsp 와 연동한다.

 

-      View 단의 jsp  Model 단에서 넘어온 결과를 브라우저에 출력 시킨다.

-      Model – View – Controller 로 기능으로 나뉘어 있기 때문에 MVC 패턴이라고도 한다.

 

 

 

 

출처  : coffeedevelop.tistory.com/28

 

 

반응형

'기타' 카테고리의 다른 글

HTTP 상태 코드  (0) 2020.12.03
HTTP 응답 코드 , 메소드 종류  (0) 2020.11.11
TCP UDP 차이점  (0) 2020.11.11
반응형

스프링 인코딩 처리

스프링은 웹 요청과 응답에 대한 인코딩 처리를 위해 CharacterEncodingFilter를 제공합니다.

인코딩 필터의 경우 모든 프로젝트에서 사용가는 공통적인 기능이므로 스프링프레임워크 측에서 번거로움을 피하기 위해 제공하는것 같습니다.

CharacterEncodingFilter 클래스는 Servlet 표준 스펙인 javax.servlet.Filter 인터페이스를 구현한 클래스이기 때문에 기존의 Servlet, JSP 에서 사용하던 필터와 똑같이 사용 가능합니다.

 

web.xml 을 통해 필터를 설정하는 경우 다음과 같이 사용가능합니다.

CharacterEncodingFilter 를 필터로 등록해두고 <init-param>의 encoding 속성을 통해 인코딩 방식을 설정해줄 수 있습니다.

또한 <filter-mapping>을 통해 어느 요청경로에 대해 필터를 적용할것인지에 대한 범위설정이 가능합니다.

이부분은 기존 필터와 사용방법이 전혀 다르지 않다는것을 알 수 있습니다.  

 <filter>

           <filter-name>encoding</filter-name>

          <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>

           <init-param>

                <param-name>encoding</param-name>

                <param-value>UTF-8</param-value>

           </init-param>

     </filter>

    

     <filter-mapping>

           <filter-name>encoding</filter-name>

           <url-pattern>/*</url-pattern>

     </filter-mapping>

  

 

응답 데이터 인코딩

기본적인 설정으로는 request 파라미터에 대한 인코딩만 처리하도록 되어있는데, 응답 데이터까지 인코딩을 처리하거나, 인코딩 설정을 강제하는 경우에는 다음과 같이 추가적으로 forceEncoding 값을 true로 적용해주면 됩니다.

 

       

 <init-param>

                <param-name>forceEncoding</param-name>

                <param-value>true</param-value>

           </init-param>

 

 

WebApplicationInitializer구현하여 설정하는 경우

서블릿 3.0에서부터는 web.xml없이 웹어플리케이션 설정을 초기화하는 기능을 제공합니다.

스프링은 그런 서블릿3.0 스펙을 이용하여 WebApplicationInitializer 라는 인터페이스를 제공하여 웹어플리케이션이 초기화 할때의 동작을 정의할 수 있도록 하고 있습니다.

만약 WebApplicationInitializer에서 CharacterEncodingFilter를 적용하는 경우 다음과 같이 사용 가능합니다.

 

 

import javax.servlet.FilterRegistration;

import javax.servlet.ServletContext;

import javax.servlet.ServletException;

import org.springframework.web.WebApplicationInitializer;

import org.springframework.web.filter.CharacterEncodingFilter;



public class MyWebAppInitializer implements WebApplicationInitializer {



     @Override

     public void onStartup(ServletContext servletContext) throws ServletException {

           FilterRegistration charEncodingFilterReg = servletContext.addFilter("CharacterEncodingFilter", CharacterEncodingFilter.class);

           charEncodingFilterReg.setInitParameter("encoding", "UTF-8");

           charEncodingFilterReg.setInitParameter("forceEncoding", "true");

           charEncodingFilterReg.addMappingForUrlPatterns(null, true, "/*");

           

     }



}

 

 

CharacterEncodingFilter 내부 구조 및 동작원리 분석

마지막으로 CharacterEncodingFilter의 소스를 열어보면 다음과 같습니다.

위에서 이미 모든것을 설명했지만 아주 간단하게 구현되어 있기 때문에 어떻게 동작하는지 궁금한 사람에게 유용할것 같습니다.

 

package org.springframework.web.filter;

import java.io.IOException;

import javax.servlet.FilterChain;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;





/**

 * Servlet Filter that allows one to specify a character encoding for requests.

 * This is useful because current browsers typically do not set a character

 * encoding even if specified in the HTML page or form.

 *

 * <p>This filter can either apply its encoding if the request does not already

 * specify an encoding, or enforce this filter's encoding in any case

 * ("forceEncoding"="true"). In the latter case, the encoding will also be

 * applied as default response encoding (although this will usually be overridden

 * by a full content type set in the view).

 *

 * @author Juergen Hoeller

 * @since 15.03.2004

 * @see #setEncoding

 * @see #setForceEncoding

 * @see javax.servlet.http.HttpServletRequest#setCharacterEncoding

 * @see javax.servlet.http.HttpServletResponse#setCharacterEncoding

 */

public class CharacterEncodingFilter extends OncePerRequestFilter {



     private String encoding;

     private boolean forceEncoding = false;



     /**

      * Set the encoding to use for requests. This encoding will be passed into a

      * {@link javax.servlet.http.HttpServletRequest#setCharacterEncoding} call.

      * <p>Whether this encoding will override existing request encodings

      * (and whether it will be applied as default response encoding as well)

      * depends on the {@link #setForceEncoding "forceEncoding"} flag.

      */

     public void setEncoding(String encoding) {

           this.encoding = encoding;

     }





     /**

      * Set whether the configured {@link #setEncoding encoding} of this filter

      * is supposed to override existing request and response encodings.

      * <p>Default is "false", i.e. do not modify the encoding if

      * {@link javax.servlet.http.HttpServletRequest#getCharacterEncoding()}

      * returns a non-null value. Switch this to "true" to enforce the specified

      * encoding in any case, applying it as default response encoding as well.

      */

     public void setForceEncoding(boolean forceEncoding) {

           this.forceEncoding = forceEncoding;

     }





     @Override

     protected void doFilterInternal(

                HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)

                throws ServletException, IOException {

           if (this.encoding != null && (this.forceEncoding || request.getCharacterEncoding() == null)) {

                request.setCharacterEncoding(this.encoding);

                if (this.forceEncoding) {

                     response.setCharacterEncoding(this.encoding);

                }

           }

           filterChain.doFilter(request, response);

     }



}



출처: https://dololak.tistory.com/123 [코끼리를 냉장고에 넣는 방법]

반응형

'Spring' 카테고리의 다른 글

HTML FORM 데이터 @ModelAttribute list로 받기  (0) 2022.03.08
반응형

정보 응답

100 Continue이 임시적인 응답은 지금까지의 상태가 괜찮으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려줍니다.101 Switching Protocol이 코드는 클라이언트가 보낸 Upgrade 요청 헤더에 대한 응답에 들어가며 서버에서 프로토콜을 변경할 것임을 알려줍니다.102 Processing (WebDAV)이 코드는 서버가 요청을 수신하였으며 이를 처리하고 있지만, 아직 제대로 된 응답을 알려줄 수 없음을 알려줍니다.
 103 Early Hints이 상태 코드는 주로 Link 헤더와 함께 사용되어 서버가 응답을 준비하는 동안 사용자 에이전트가(user agent) 사전 로딩(preloading)을 시작할 수 있도록 한다.

성공 응답

200 OK요청이 성공적으로 되었습니다. 성공의 의미는 HTTP 메소드에 따라 달라집니다:
GET: 리소스를 불러와서 메시지 바디에 전송되었습니다.
HEAD: 개체 해더가 메시지 바디에 있습니다.
PUT 또는 POST: 수행 결과에 대한 리소스가 메시지 바디에 전송되었습니다.
TRACE: 메시지 바디는 서버에서 수신한 요청 메시지를 포함하고 있습니다.
 201 Created요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었습니다. 이 응답은 일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라옵니다.202 Accepted요청을 수신하였지만 그에 응하여 행동할 수 없습니다. 이 응답은 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않습니다. 이것은 다른 프로세스에서 처리 또는 서버가 요청을 다루고 있거나 배치 프로세스를 하고 있는 경우를 위해 만들어졌습니다.203 Non-Authoritative Information이 응답 코드는 돌려받은 메타 정보 세트가 오리진 서버의 것과 일치하지 않지만 로컬이나 서드 파티 복사본에서 모아졌음을 의미합니다. 이러한 조건에서는 이 응답이 아니라 200 OK 응답을 반드시 우선됩니다.204 No Content요청에 대해서 보내줄 수 있는 콘텐츠가 없지만, 헤더는 의미있을 수 있습니다. 사용자-에이전트는 리소스가 캐시된 헤더를 새로운 것으로 업데이트 할 수 있습니다.205 Reset Content이 응답 코드는 요청을 완수한 이후에 사용자 에이전트에게 이 요청을 보낸 문서 뷰를 리셋하라고 알려줍니다.206 Partial Content이 응답 코드는 클라이언트에서 복수의 스트림을 분할 다운로드를 하고자 범위 헤더를 전송했기 때문에 사용됩니다.207 Multi-Status (WebDAV)멀티-상태 응답은 여러 리소스가 여러 상태 코드인 상황이 적절한 경우에 해당되는 정보를 전달합니다.208 Multi-Status (WebDAV)DAV에서 사용됩니다: propstat(property와 status의 합성어) 응답 속성으로 동일 컬렉션으로 바인드된 복수의 내부 멤버를 반복적으로 열거하는 것을 피하기 위해 사용됩니다.226 IM Used (HTTP Delta encoding)서버가 GET 요청에 대한 리소스의 의무를 다 했고, 그리고 응답이 하나 또는 그 이상의 인스턴스 조작이 현재 인스턴스에 적용이 되었음을 알려줍니다.


 

리다이렉션 메시지

300 Multiple Choice요청에 대해서 하나 이상의 응답이 가능합니다. 사용자 에이전트 또는 사용자는 그중에 하나를 반드시 선택해야 합니다. 응답 중 하나를 선택하는 방법에 대한 표준화 된 방법은 존재하지 않습니다.301 Moved Permanently이 응답 코드는 요청한 리소스의 URI가 변경되었음을 의미합니다. 새로운 URI가 응답에서 아마도 주어질 수 있습니다.302 Found이 응답 코드는 요청한 리소스의 URI가 일시적으로 변경되었음을 의미합니다. 새롭게 변경된 URI는 나중에 만들어질 수 있습니다. 그러므로, 클라이언트는 향후의 요청도 반드시 동일한 URI로 해야합니다.303 See Other클라이언트가 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 할 때, 서버가 클라이언트로 직접 보내는 응답입니다.304 Not Modified이것은 캐시를 목적으로 사용됩니다. 이것은 클라이언트에게 응답이 수정되지 않았음을 알려주며, 그러므로 클라이언트는 계속해서 응답의 캐시된 버전을 사용할 수 있습니다.305 Use Proxy 이전 버전의 HTTP 기술 사양에서 정의되었으며, 요청한 응답은 반드시 프록시를 통해서 접속해야 하는 것을 알려줍니다. 이것은 프록시의 in-band 설정에 대한 보안상의 걱정으로 인하여 사라져가고 있습니다.306 unused이 응답 코드는 더이상 사용되지 않으며, 현재는 추후 사용을 위해 예약되어 있습니다. 이것은 HTTP 1.1 기술사양 이전 버전에서 사용되었습니다.307 Temporary Redirect클라리언트가 요청한 리소스가 다른 URI에 있으며, 이전 요청과 동일한 메소드를 사용하여 요청해야할 때, 서버가 클라이언트에 이 응답을 직접 보냅니다. 이것은 302 Found HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 사용된 HTTP 메소드를 변경하지 말아야 하는 점만 다릅니다: 만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 합니다.308 Permanent Redirect이것은 리소스가 이제 HTTP 응답 헤더의 Location: 에 명시된 영구히 다른 URI에 위치하고 있음을 의미합니다. 이것은 301 Moved Permanently HTTP 응답 코드와 동일한  의미를 가지고 있으며, 사용자 에이전트가 반드시 HTTP 메소드를 변경하지 말아야 하는 점만 다릅니다: 만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 합니다.
 

클라이언트 에러 응답

400 Bad Request이 응답은 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음을 의미합니다.401 Unauthorized비록 HTTP 표준에서는 "미승인(unauthorized)"를 명확히 하고 있지만, 의미상 이 응답은 "비인증(unauthenticated)"을 의미합니다. 클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 합니다.402 Payment Required이 응답 코드는 나중에 사용될 것을 대비해 예약되었습니다. 첫 목표로는 디지털 결제 시스템에 사용하기 위하여 만들어졌지만 지금 사용되고 있지는 않습니다.403 Forbidden클라이언트는 콘텐츠에 접근할 권리를 가지고 있지 않습니다. 예를들어 그들은 미승인이어서 서버는 거절을 위한 적절한 응답을 보냅니다. 401과 다른 점은 서버가 클라이언트가 누구인지 알고 있습니다.404 Not Found서버는 요청받은 리소스를 찾을 수 없습니다. 브라우저에서는 알려지지 않은 URL을 의미합니다. 이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수도 있습니다. 서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위하여 이 응답을 403 대신에 전송할 수도 있습니다. 이 응답 코드는 웹에서 반복적으로 발생하기 때문에 가장 유명할지도 모릅니다.405 Method Not Allowed요청한 메소드는 서버에서 알고 있지만, 제거되었고 사용할 수 없습니다. 예를 들어, 어떤 API에서 리소스를 삭제하는 것을 금지할 수 있습니다. 필수적인 메소드인 GET과 HEAD는 제거될 수 없으며 이 에러 코드를 리턴할 수 없습니다.406 Not Acceptable이 응답은 서버가 서버 주도 콘텐츠 협상 을 수행한 이후, 사용자 에이전트에서 정해준 규격에 따른 어떠한 콘텐츠도 찾지 않았을 때, 웹서버가 보냅니다.407 Proxy Authentication Required이것은 401과 비슷하지만 프록시에 의해 완료된 인증이 필요합니다.408 Request Timeout이 응답은 요청을 한지 시간이 오래된 연결에 일부 서버가 전송하며, 어떨 때에는 이전에 클라이언트로부터 어떠한 요청이 없었다고 하더라도 보내지기도 합니다. 이것은 서버가 사용되지 않는 연결을 끊고 싶어한다는 것을 의미합니다. 이 응답은 특정 몇몇 브라우저에서 빈번하게 보이는데, Chrome, Firefox 27+, 또는 IE9와 같은 웹서핑 속도를 올리기 위해 HTTP 사전 연결 메카니즘을 사용하는 브라우저들이 해당됩니다. 또한 일부 서버는 이 메시지를 보내지 않고 연결을 끊어버리기도 합니다.409 Conflict이 응답은 요청이 현재 서버의 상태와 충돌될 때 보냅니다.410 Gone이 응답은 요청한 콘텐츠가 서버에서 영구적으로 삭제되었으며, 전달해 줄 수 있는 주소 역시 존재하지 않을 때 보냅니다. 클라이언트가 그들의 캐쉬와 리소스에 대한 링크를 지우기를 기대합니다. HTTP 기술 사양은 이 상태 코드가 "일시적인, 홍보용 서비스"에 사용되기를 기대합니다. API는 알려진 리소스가 이 상태 코드와 함께 삭제되었다고 강요해서는 안된다.411 Length Required서버에서 필요로 하는 Content-Length 헤더 필드가 정의되지 않은 요청이 들어왔기 때문에 서버가 요청을 거절합니다.412 Precondition Failed클라이언트의 헤더에 있는 전제조건은 서버의 전제조건에 적절하지 않습니다.413 Payload Too Large요청 엔티티는 서버에서 정의한 한계보다 큽니다; 서버는 연결을 끊거나 혹은 Retry-After 헤더 필드로 돌려보낼 것이다.414 URI Too Long클라이언트가 요청한 URI는 서버에서 처리하지 않기로 한 길이보다 깁니다.415 Unsupported Media Type요청한 미디어 포맷은 서버에서 지원하지 않습니다, 서버는 해당 요청을 거절할 것입니다.416 Requested Range Not SatisfiableRange 헤더 필드에 요청한 지정 범위를 만족시킬 수 없습니다; 범위가 타겟 URI 데이터의 크기를 벗어났을 가능성이 있습니다.417 Expectation Failed이 응답 코드는 Expect 요청 헤더 필드로 요청한 예상이 서버에서는 적당하지 않음을 알려줍니다.418 I'm a teapot서버는 커피를 찻 주전자에 끓이는 것을 거절합니다.421 Misdirected Request서버로 유도된 요청은 응답을 생성할 수 없습니다. 이것은 서버에서 요청 URI와 연결된 스킴과 권한을 구성하여 응답을 생성할 수 없을 때 보내집니다.422 Unprocessable Entity (WebDAV)요청은 잘 만들어졌지만, 문법 오류로 인하여 따를 수 없습니다.423 Locked (WebDAV)리소스는 접근하는 것이 잠겨있습니다.424 Failed Dependency (WebDAV)이전 요청이 실패하였기 때문에 지금의 요청도 실패하였습니다.426 Upgrade Required서버는 지금의 프로토콜을 사용하여 요청을 처리하는 것을 거절하였지만, 클라이언트가 다른 프로토콜로 업그레이드를 하면 처리를 할지도 모릅니다. 서버는 Upgrade 헤더와 필요로 하는 프로토콜을 알려주기 위해 426 응답에 보냅니다.428 Precondition Required오리진 서버는 요청이 조건적이어야 합니다. 클라이언트가 리소스를 GET해서, 수정하고, 그리고 PUT으로 서버에 돌려놓는 동안 서드파티가 서버의 상태를 수정하여 발생하는 충돌인 '업데이트 상실'을 예방하기 위한 목적입니다.429 Too Many Requests사용자가 지정된 시간에 너무 많은 요청을 보냈습니다("rate limiting").431 Request Header Fields Too Large요청한 헤더 필드가 너무 크기 때문에 서버는 요청을 처리하지 않을 것입니다. 요청은 크기를 줄인 다음에 다시 전송해야 합니다.451 Unavailable For Legal Reasons사용자가 요청한 것은 정부에 의해 검열된 웹 페이지와 같은 불법적인 리소스입니다.

서버 에러 응답

500 Internal Server Error서버가 처리 방법을 모르는 상황이 발생했습니다. 서버는 아직 처리 방법을 알 수 없습니다.501 Not Implemented요청 방법은 서버에서 지원되지 않으므로 처리할 수 없습니다. 서버가 지원해야 하는 유일한 방법은 GET와 HEAD이다. 이 코드는 반환하면 안됩니다.502 Bad Gateway이 오류 응답은 서버가 요청을 처리하는 데 필요한 응답을 얻기 위해 게이트웨이로 작업하는 동안 잘못된 응답을 수신했음을 의미합니다.503 Service Unavailable서버가 요청을 처리할 준비가 되지 않았습니다. 일반적인 원인은 유지보수를 위해 작동이 중단되거나 과부하가 걸렸을 때 입니다. 이 응답과 함께 문제를 설명하는 사용자 친화적인 페이지가 전송되어야 한다는 점에 유의하십시오. 이 응답은 임시 조건에 사용되어야 하며, Retry-After: HTTP 헤더는 가능하면 서비스를 복구하기 전 예상 시간을 포함해야 합니다. 웹마스터는 또한 이러한 일시적인 조건 응답을 캐시하지 않아야 하므로 이 응답과 함께 전송되는 캐싱 관련 헤더에 대해서도 주의해야 합니다.504 Gateway Timeout이 오류 응답은 서버가 게이트웨이 역할을 하고 있으며 적시에 응답을 받을 수 없을 때 주어집니다.505 HTTP Version Not Supported요청에 사용된 HTTP 버전은 서버에서 지원되지 않습니다.506 Variant Also Negotiates서버에 내부 구성 오류가 있다. 즉, 요청을 위한 투명한 컨텐츠 협상이 순환 참조로 이어진다.507 Insufficient Storage서버에 내부 구성 오류가 있다. 즉, 선택한 가변 리소스는 투명한 콘텐츠 협상에 참여하도록 구성되므로 협상 프로세스의 적절한 종료 지점이 아닙니다.508 Loop Detected (WebDAV)서버가 요청을 처리하는 동안 무한 루프를 감지했습니다.510 Not Extended서버가 요청을 이행하려면 요청에 대한 추가 확장이 필요합니다.511 Network Authentication Required511 상태 코드는 클라이언트가 네트워크 액세스를 얻기 위해 인증을 받아야 할 필요가 있음을 나타냅니다.

브라우저 호환성

The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.

Update compatibility data on GitHub

DesktopMobileChromeEdgeFirefoxInternet ExplorerOperaSafariAndroid webviewChrome for AndroidFirefox for AndroidOpera for AndroidSafari on iOSSamsung Internet100200201204206301302303304307308401403404406407409410412416418425451500501502503504

Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full support36 Full support12 Full support14 Full support11

Notes

열기
Full support24 Full support7 Full support37 Full support36 Full support14 Full support24 Full support7 Full support3.0
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
? ? Full support58 ? ? ? ? ? Full support58 ? ? ?
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes
Full supportYes Full support12 Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes Full supportYes

 

 

출처 :developer.mozilla.org/ko/docs/Web/HTTP/Status

반응형

'기타' 카테고리의 다른 글

Model1 vs Model2  (0) 2020.12.07
HTTP 응답 코드 , 메소드 종류  (0) 2020.11.11
TCP UDP 차이점  (0) 2020.11.11
반응형

아래는 HTTP(하이퍼텍스트 전송 프로토콜) 응답 상태 코드의 목록이다.

IANA가 현재 공식 HTTP 상태 코드 레지스트리를 관리하고 있다.

모든 HTTP 응답 코드는 5개의 클래스(분류)로 구분된다. 상태 코드의 첫 번째 숫자는 응답의 클래스를 정의한다. 마지막 두 자리는 클래스나 분류 역할을 하지 않는다. 첫자리에 대한 5가지 값들은 다음과 같다:

  • 1xx (정보): 요청을 받았으며 프로세스를 계속한다
  • 2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다
  • 3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다
  • 4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다
  • 5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다

 

HTTP 응답 코드 종류

 응답 코드

설명 

100 

 Continue (클라이언트로 부터 일부 요청을 받았으며 나머지 정보를 계속 요청함)

 101

 Switching protocols

 200

 OK(요청이 성공적으로 수행되었음)

 201

 Created (PUT 메소드에 의해 원격지 서버에 파일 생성됨)

 202

 Accepted(웹 서버가 명령 수신함)

 203

 Non-authoritative information (서버가 클라이언트 요구 중 일부만 전송)

 204

 No content, (사용자 요구 처리하였으나 전송할 데이터가 없음)

 301

 Moved permanently (요구한 데이터를 변경된 타 URL에 요청함)

 302

 Not temporarily

 304

 Not modified (컴퓨터 로컬의 캐시 정보를 이용함, 대개 gif 등은 웹 서버에 요청하지 않음)

 400

 Bad request (사용자의 잘못된 요청을 처리할 수 없음)

 401

 Unauthorized (인증이 필요한 페이지를 요청한 경우)

 402

 Payment required(예약됨)

 403

 Forbidden (접근 금지, 디렉터리 리스팅 요청 및 관리자 페이지 접근 등을 차단)

 404

 Not found, (요청한 페이지 없음)

 405

 Method not allowed (혀용되지 않는 http method 사용함)

 407

 Proxy authentication required (프락시 인증 요구됨)

 408

 Request timeout (요청 시간 초과)

 410

 Gone (영구적으로 사용 금지)

 412

 Precondition failed (전체 조건 실패)

 414

 Request-URI too long (요청 URL 길이가 긴 경우임)

 500

 Internal server error (내부 서버 오류)

 501

 Not implemented (웹 서버가 처리할 수 없음)

 503

 Service unnailable (서비스 제공 불가)

 504

 Gateway timeout (게이트웨이 시간 초과)

 505

 HTTP version not supported (해당 http 버전 지원되지 않음)

 

 

HTTP 메소드 종류

 HTTP Method

전송 형태 

설명 

 GET

GET [request-uri]?query_string

HTTP/1.1\r\n

Host:[Hostname] 혹은 [IP] \r\n 

 GET 요청 방식은 URI(URL)가 가진 정보를 검색하기 위해 서버 측에 요청하는형태이다

 

 HTTP Method

전송 형태 

설명 

 POST

POST [request-uri]?query_string

HTTP/1.1\r\n

HOST:[Hostname] 혹은 [IP] \r\n

Content-Lenght:[Lenght in Bytes] \r\n 

\r\n

[query-string] 혹은 [데이터]

POST 요청 방식은 요청 URI(URL)에 폼 입력을 처리하기 위해 구성한 서버 측 스크립트(ASP, PHP, JSP 등) 혹은 CGI 프로그램으로 구성되고 Form Action과 함께 전송되는데, 이때 헤더 정보에 포함되지 않고 데이터 부분에 요청 정보가 들어가게 된다. 

 

 HTTP Method

전송 형태 

설명 

 HEAD

HEAD [request-uri] HTTP/1.1\r\n

Host:[Hostname] 혹은 [IP] \r\n 

HEAD 요청 방식은 GET과 유사한 방식이나 웹 서버에서 헤더 정보 이외에는 어떤 데이터도 보내지 않는다.

웹 서버의 다운 여부 점검(Health Check)이나 웹 서버 정보(버전 등)등을 얻기 위해 사용될 수 있다. 

 

 HTTP Method

전송 형태 

설명 

 OPTIONS

OPTIONS [request-ri]

HTTP/1.1\r\n

Host:[Hostname] 혹은 [IP] \r\n 

해당 메소드를 통해 시스템에서 지원되는 메소드 종류를 확인할 수 있다. 

 

 HTTP Method

전송 형태 

설명 

 PUT

PUT [request-uri] HTTP/1.1\r\n

Host:[Hostname] 혹은 [IP] \r\n

Content-Lenght:[Length in Bytes] \r\n

Content-Type:[Content Type] \r\n

\r\n

[데이터] 

 POST와 유사한 전송 구조를 가지기 때문에 헤더 이외에 메시지(데이터)가 함께 전송된다.

원격지 서버에 지정한 콘텐츠를 저장하기 위해 사용되며 홈페이지 변조에 많이 악용되고 있다.

 

 HTTP Method

전송 형태 

설명 

 DELETE

DELETE [request-uri] HTTP/1.1\r\n

Host:[Hostname] 혹은 [IP] \r\n

\r\n 

 원격지 웹 서버에 파일을 삭제하기 위해 사용되며 PUT과는 반대 개념의 메소드이다.

 

 HTTP Method

전송 형태 

설명 

 TRACE

TRACE [request-uri] HTTP/1.1\r\n

Host:[Hostname] 혹은 [IP] \r\n

\r\n 

원격지 서버에 Loopback(루프백) 메시지를 호출하기 위해 사용된다. 

 

 HTTP Method

전송 형태 

설명 

 CONNECT

CONNECT [request-uri] HTTP/1.1\r\n

Host:[Hostname] 혹은 [IP] \r\n

\r\n 

 웹 서버에 프락시 기능을 요청할 때 사용된다.

 



출처: https://gyrfalcon.tistory.com/entry/HTTP-응답-코드-종류-HTTP-메소드-종류 [Minsub's Blog]

출처: https://gyrfalcon.tistory.com/entry/HTTP-응답-코드-종류-HTTP-메소드-종류 [Minsub's Blog]

반응형

'기타' 카테고리의 다른 글

Model1 vs Model2  (0) 2020.12.07
HTTP 상태 코드  (0) 2020.12.03
TCP UDP 차이점  (0) 2020.11.11
반응형

1. 전송계층

이전 글에서 TCP/IP 모델에 대해 공부했다. TCP와 UDP는 TCP/IP의 전송계층에서 사용되는 프로토콜이다. 전송계층은 IP에 의해 전달되는 패킷의 오류를 검사하고 재전송 요구 등의 제어를 담당하는 계층이다.

2. TCP vs UDP

TCP는 Transmission Control Protocol의 약자이고, UDP는 User Datagram Protocol의 약자이다. 두 프로토콜은 모두 패킷을 한 컴퓨터에서 다른 컴퓨터로 전달해주는 IP 프로토콜을 기반으로 구현되어 있지만, 서로 다른 특징을 가지고 있다.

그림으로 비교하는 TCP vs UDP

먼저, TCP의 데이터 송신 과정을 살펴보자.

반면, UDP는 일방적이다.

즉, 신뢰성이 요구되는 애플리케이션에서는 TCP를 사용하고 간단한 데이터를 빠른 속도로 전송하고자 하는 애플리케이션에서는 UDP를 사용한다.

표로 비교하는 TCP vs UDP

TCPUDP

Connection-oriented protocol
(연결지향형 프로토콜)
Connection-less protocol
(비 연결지향형 프로토콜)
Connection by byte stream
(바이트 스트림을 통한 연결)
Connection by message stream
(메세지 스트림을 통한 연결)
Congestion / Flow control
(혼잡제어, 흐름제어)
NO Congestion / Flow control
(혼잡제어와 흐름제어 지원 X)
Ordered, Lower speed
(순서 보장, 상대적으로 느림)
Not ordered, Higer speed
(순서 보장되지 않음, 상대적으로 빠름)
Reliable data transmission
(신뢰성 있는 데이터 전송 - 안정적)
Unreliable data transmission
(데이터 전송 보장 X)
TCP packet : Segment
(세그먼트 TCP 패킷)
UDP packet : Datagram
(데이터그램 UDP 패킷)
HTTP, Email, File transfer
에서 사용
DNS, Broadcasting
(도메인, 실시간 동영상 서비스에서 사용)

3. TCP (Transmission Control Protocol)

TCP는 네트워크 계층 중 전송 계층에서 사용하는 프로토콜로서, 장치들 사이에 논리적인 접속을 성립(establish)하기 위하여 연결을 설정하여 신뢰성을 보장하는 연결형 서비스 이다. TCP는 네트워크에 연결된 컴퓨터에서 실행되는 프로그램 간에 일련의 옥텟(데이터, 메세지, 세그먼트라는 블록 단위)를 안정적으로, 순서대로, 에러없이 교환할 수 있게 한다.

3.1. TCP의 특징

연결형 서비스

연결형 서비스로 가상 회선 방식을 제공한다.

  • 3-way handshaking 과정을 통해 연결을 설정
  • 4-way handshaking 을 통해 연결을 해제.

흐름제어(Flow control)

데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지

  • 송신하는 곳에서 감당이 안되게 많은 데이터를 빠르게 보내 수신하는 곳에서 문제가 일어나는 것을 막는다.
  • 수신자가 윈도우크기(Window Size) 값을 통해 수신량을 정할 수 있다.

혼잡제어(Congestion control)

네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지

  • 정보의 소통량이 과다하면 패킷을 조금만 전송하여 혼잡 붕괴 현상이 일어나는 것을 막는다.

신뢰성이 높은 전송(Reliable transmission)

  • Dupack-based retransmission
    • 정상적인 상황에서는 ACK 값이 연속적으로 전송되어야 한다.
    • 그러나 ACK값이 중복으로 올 경우 패킷 이상을 감지하고 재전송을 요청한다.
  • Timeout-based retransmission
    • 일정시간동안 ACK 값이 수신을 못할 경우 재전송을 요청한다.

전이중, 점대점 방식

  • 전이중 (Full-Duplex)
    전송이 양방향으로 동시에 일어날 수 있다.
  • 점대점 (Point to Point)
    각 연결이 정확히 2개의 종단점을 가지고 있다.

=> 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.

3.2. TCP Header 정보

응용 계층으로부터 데이터를 받은 TCP는 헤더를 추가한 후에 이를 IP로 보낸다. 헤더에는 아래 표와 같은 정보가 포함된다.

필 드내 용크 기

송수신자의 포트 번호 TCP로 연결되는 가상 회선 양단의 송수신 프로세스에 할당되는 포트 주소 16
시퀀스 번호(Sequence Number) 송신자가 지정하는 순서 번호, 전송되는 바이트 수를 기준으로 증가.
SYN = 1 : 초기 시퀀스 번호가 된다. ACK 번호는 이 값에 1을 더한 값.
SYN = 0 : 현재 세션의 이 세그먼트 데이터의 최초 바이트 값의 누적 시퀀스 번호
32
응답 번호(ACK Number) 수신 프로세스가 제대로 수신한 바이트의 수를 응답하기 위해 사용. 32
데이터 오프셋(Data Offset) TCP 세그먼트의 시작 위치를 기준으로 데이터의 시작 위치를 표현(TCP 헤더의 크기) 4
예약 필드(Reserved) 사용을 하지 않지만 나중을 위한 예약 필드이며 0으로 채워져야한다. 6
제어 비트(Flag Bit) SYN, ACK, FIN 등의 제어 번호 -> 아래 추가 설명 참조 6
윈도우 크기(Window) 수신 윈도우의 버퍼 크기를 지정할 때 사용. 0이면 송신 프로세스의 전송 중지 16
체크섬(Checksum) TCP 세그먼트에 포함되는 프로토콜 헤더와 데이터에 대한 오류 검출 용도 16
긴급 위치(Urgent Pointer) 긴급 데이터를 처리하기 위함, URG 플래그 비트가 지정된 경우에만 유효 16

제어 비트(Flag Bit) 정보

종 류내 용

URG 긴급 위치를 필드가 유효한지 설정
ACK 응답 번호 필드가 유효한지 설정. 클라이언트가 보낸 최초의 SYN 패킷 이후에 전송되는 모든 패킷은 이 플래그가 설정되어야 한다. 자세한 내용은 아래 추가 설명 참조
PSH 수신 애플리케이션에 버퍼링된 데이터를 상위 계층에 즉시 전달할 때
RST 연결의 리셋이나 유효하지 않은 세그먼트에 대한 응답용
SYN 연결 설정 요구. 동기화 시퀀스 번호. 양쪽이 보낸 최초의 패킷에만 이 플래그가 설정되어 있어야 한다.
FIN 더 이상 전송할 데이터가 없을 때 연결 종료 의사 표시

ACK 제어비트

  • ACK는 송신측에 대하여 수신측에서 긍정 응답으로 보내지는 전송 제어용 캐릭터

  • ACK 번호를 사용하여 패킷이 도착했는지 확인한다.

    -> 송신한 패킷이 제대로 도착하지 않았으면 재송신을 요구한다.

3.3. TCP의 연결 및 해제 과정

TCP Connection (3-way handshake)

  1. 먼저 open()을 실행한 클라이언트가 SYN을 보내고 SYN_SENT 상태로 대기한다.
  2. 서버는 SYN_RCVD 상태로 바꾸고 SYN과 응답 ACK를 보낸다.
  3. SYN과 응답 ACK을 받은 클라이언트는 ESTABLISHED 상태로 변경하고 서버에게 응답 ACK를 보낸다.
  4. 응답 ACK를 받은 서버는 ESTABLISHED 상태로 변경한다.

TCP Disconnection (4-way handshake)

  1. 먼저 close()를 실행한 클라이언트가 FIN을 보내고 FIN_WAIT1 상태로 대기한다.
  2. 서버는 CLOSE_WAIT으로 바꾸고 응답 ACK를 전달한다. 동시에 해당 포트에 연결되어 있는 어플리케이션에게 close()를 요청한다.
  3. ACK를 받은 클라이언트는 상태를 FIN_WAIT2로 변경한다.
  4. close() 요청을 받은 서버 어플리케이션은 종료 프로세스를 진행하고 FIN을 클라이언트에 보내 LAST_ACK 상태로 바꾼다.
  5. FIN을 받은 클라이언트는 ACK를 서버에 다시 전송하고 TIME_WAIT으로 상태를 바꾼다. TIME_WAIT에서 일정 시간이 지나면 CLOSED된다. ACK를 받은 서버도 포트를 CLOSED로 닫는다.
주의
  • 반드시 서버만 CLOSE_WAIT 상태를 갖는 것은 아니다.
  • 서버가 먼저 종료하겠다고 FIN을 보낼 수 있고, 이런 경우 서버가 FIN_WAIT1 상태가 됩니다.
  • 누가 먼저 close를 요청하느냐에 따라 상태가 달라질 수 있다.

4. UPD Header 정보

응용 계층으로부터 데이터 받은 UDP도 UDP 헤더를 추가한 후에 이를 IP로 보낸다.

필 드크 기내 용

송신자의 포트 번호 16 데이터를 보내는 애플리케이션의 포트 번호
수신자의 포트 번호 16 데이터를 받을 애플리케이션의 포트 번호
데이터의 길이 16 UDP 헤더와 데이터의 총 길이
체크섬(Checksum) 16 데이터 오류 검사에 사용

TCP 헤더와 다르게 UDP 헤더에는 포함된 정보가 부실한 느낌마저 든다.
UDP는 수신자가 데이터를 받는지 마는지 관심이 없기 때문이다. 즉, 신뢰성을 보장해주지 않지만 간단하고 속도가 빠른 것이 특징이다.

5. 정리

공통점

TCP(Transfer Control Protocol) | UDP(User Datagram Protocol)

포트 번호를 이용하여 주소를 지정
데이터 오류 검사를 위한 체크섬 존재

차이점

TCP(Transfer Control Protocol)UDP(User Datagram Protocol)

연결이 성공해야 통신 가능(연결형 프로토콜) 비연결형 프로토콜(연결 없이 통신이 가능)
데이터의 경계를 구분하지 않음(Byte-Stream Service) 데이터의 경계를 구분함(Datagram Service)
신뢰성 있는 데이터 전송(데이터의 재전송 존재) 비신뢰성 있는 데이터 전송(데이터의 재전송 없음)
일 대 일(Unicast) 통신 일 대 일, 일 대 다(Broadcast), 다 대 다(Multicast) 통신

6. 참고

https://www.slideshare.net/bluem31/tcp-47441568?qid=04ddad59-7ebb-4557-99d7-50435e9a5f92&v=&b=&from_search=5

https://madplay.github.io/post/network-tcp-udp-tcpip

https://m.blog.naver.com/PostView.nhn?blogId=ksg7514&logNo=220772997742&proxyReferer=https:%2F%2Fwww.google.com%2F

https://gmlwjd9405.github.io/2018/09/19/tcp-connection.html

 

[Network] TCP 3-way handshaking과 4-way handshaking - Heee's Development Blog

Step by step goes a long way.

gmlwjd9405.github.io

 

 

 

출처 :  velog.io/@hidaehyunlee/TCP-%EC%99%80-UDP-%EC%9D%98-%EC%B0%A8%EC%9D%B4

반응형

'기타' 카테고리의 다른 글

Model1 vs Model2  (0) 2020.12.07
HTTP 상태 코드  (0) 2020.12.03
HTTP 응답 코드 , 메소드 종류  (0) 2020.11.11
반응형

1. TO_CHAR 함수 이용

SELECT  TO_CHAR( num_col , '999,999,999,999,999')
FROM  TEMP

주의)999,999 패턴을 주실때는 충분히 큰 숫자를 주셔야 합니다. 조회될 수 있는 값보다
       작으면 출력이 안될 수도 있습니다.

2. REGEXP_REPLACE 함수 이용

SELECT NO

      ,REVERSE(TO_CHAR(no)) AS REVERSE_NO

      ,REGEXP_REPLACE(REVERSE(REGEXP_REPLACE( REVERSE(TO_CHAR(no)), '([0-9]{3})','\1,')), '^,','') AS COMMA_NO

FROM

(

  SELECT 123456789 AS no

  FROM dual

) V1

;

<<결과>>

NO REVERSE_NO COMMA_NO

---   -------------    -------------

123456789 987654321 123,456,789

 

TO_CHAR 함수를 이용하는 방법은 쉽지만 자릿수를 잘 고려하여 패턴을 넣어줘야 불편함이 있고,

REGEXP_REPLACE 함수는 자릿수를 고려하지 않아도 되지만 사용방법이 어렵다는 특징이 있습니다.

상황에 맞게 골라서 사용하시면 되겠습니다.

 

--- FROM dev4u ---



출처: https://dev4u.tistory.com/100 [데브포유]

반응형

'Oracle' 카테고리의 다른 글

Oracle %ROWTYPE  (0) 2019.07.03
오라클 월 처음&마지막 날짜 구하기  (0) 2019.04.25
해당 날짜의 일요일 구하기  (0) 2019.04.02
Oracle Characterset  (1) 2019.01.03
Oracle 테이블 컬럼 추가  (0) 2018.12.27
반응형

%ROWTYPE

  테이블이나 뷰 내부의 컬럼 데이터형, 크기, 속석등을 그대로 사용 할 수 있다.

  %ROWTYPE 앞에 오는 것은 데이터베이스 테이블 이름이다.

  지정된 테이블의 구조와 동일한 구조를 갖는 변수를 선언 할 수 있다.

  데이터베이스 컬럼들의 수나 DATATYPE을 알지 못할 때 편리 하다.

  테이블의 데이터 컬럼의 DATATYPE이 변경 될 경우 프로그램을 재수정할 필요가 없다.

 

 

 

 

%ROWTYPE 예제

SQL>CREATE OR REPLACE PROCEDURE RowType_Test

( p_empno IN emp.empno%TYPE )

 

IS

 

-- %ROWTYPE 변수 선언,

-- emp테이블의 속성을 그대로 사용할 수 있다.

v_emp emp%ROWTYPE ;

 

BEGIN

 

DBMS_OUTPUT.ENABLE;

 

-- %ROWTYPE 변수 사용

 

SELECT empno, ename, hiredate

INTO v_emp.empno, v_emp.ename, v_emp.hiredate

FROM emp

WHERE empno = p_empno;

 

DBMS_OUTPUT.PUT_LINE( '사원번호 : ' || v_emp.empno );

DBMS_OUTPUT.PUT_LINE( '사원이름 : ' || v_emp.ename );

DBMS_OUTPUT.PUT_LINE( '입 사 일 : ' || v_emp.hiredate );

END;

/

 

-- DBMS_OUTPUT.PUT_LINE을 출력하기 위해 사용

SQL> SET SERVEROUTPUT ON ;

 

-- 실행 결과

SQL> EXECUTE RowType_Test(7900);

 

사원번호 : 7900

사원이름 : JAMES

입 사 일 : 81/12/03

 

 

PL/SQL 처리가 정상적으로 완료되었습니다.

참고링크

- 강좌 URL : http://www.gurubee.net/lecture/1046

- 구루비 강좌는 개인의 학습용으로만 사용 할 수 있으며, 다른 웹 페이지에 게재할 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^

- 구루비 강좌는 서비스 제공을 위한 목적이나, 학원 홍보, 수익을 얻기 위한 용도로 사용 할 수 없습니다.

 

 

반응형

'Oracle' 카테고리의 다른 글

oracle 천단위(3자리) 콤마  (1) 2019.07.26
오라클 월 처음&마지막 날짜 구하기  (0) 2019.04.25
해당 날짜의 일요일 구하기  (0) 2019.04.02
Oracle Characterset  (1) 2019.01.03
Oracle 테이블 컬럼 추가  (0) 2018.12.27
반응형

// epoch를 이용하여 초 단위로 계산

// 60을 나눈 이유는 분으로 계산하기 위하여

 

select round(extract(epoch from ('2200'::time - '1800'::time))::numeric/60);

 

 select round(extract(epoch from ('2019-06-07 2200'::timestamp - '2019-06-06 1800'::timestamp))::numeric/60);

반응형

'Postgresql' 카테고리의 다른 글

postgresql 날짜 연산  (0) 2019.05.10
MONTHS_BETWEEN ORACLE -> POSTGRESQL 변경하기  (0) 2019.04.01
코드 4자리로 뽑기  (0) 2019.02.26
Oracle INSTR 함수 -> position 변경  (0) 2019.01.28
Postgresql Merge into  (0) 2019.01.28

+ Recent posts