WO2012029247A1 - データ転送システム - Google Patents

データ転送システム Download PDF

Info

Publication number
WO2012029247A1
WO2012029247A1 PCT/JP2011/004665 JP2011004665W WO2012029247A1 WO 2012029247 A1 WO2012029247 A1 WO 2012029247A1 JP 2011004665 W JP2011004665 W JP 2011004665W WO 2012029247 A1 WO2012029247 A1 WO 2012029247A1
Authority
WO
WIPO (PCT)
Prior art keywords
site
server
domain resolution
domain
parent
Prior art date
Application number
PCT/JP2011/004665
Other languages
English (en)
French (fr)
Inventor
泰寛 宮尾
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to US13/818,147 priority Critical patent/US20130151664A1/en
Priority to JP2012531671A priority patent/JP5803924B2/ja
Publication of WO2012029247A1 publication Critical patent/WO2012029247A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0864—Round trip delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/70—Routing based on monitoring results
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5682—Policies or rules for updating, deleting or replacing the stored data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols

Definitions

  • the present invention relates to a data transfer system, and more particularly, to a system for transferring data between a plurality of computers distributed on a network.
  • the data transfer system shown in FIG. 1 includes client devices 41 to 44 and a distribution system 22.
  • the distribution system 22 provides various services such as posting and distribution of contents to the client apparatuses 41 to 44, and includes a plurality of sites 101 to 104 and a subnetwork 18 connecting them.
  • one or a plurality of server devices that can process or store data are installed in the sites 101 to 104 described above. It shall refer to the place to do.
  • the server device is connected to the edge router 20 located for accessing the Internet by the multilayer switch 19.
  • Site installations range from small servers that store server devices in a rack and are installed on the floor in a building, to Internet data centers (iDC) that house a huge number of server devices. .
  • iDC Internet data centers
  • CDN Content Delivery Network
  • data may be replicated from a website hosting content data such as a website or video issued by a content holder (also called an origin site) to an edge site that delivers to end users.
  • content data is transferred from the origin site to the edge site when desired content with a valid time limit is not cached at the edge site accessed by the content user.
  • data that cannot be cached originally generated dynamically at the origin site is transferred from the origin site to the edge site accessed by the end user. In all of these examples, if data can be transferred from the origin site to the edge site at a high speed, the experience and satisfaction of the end user can be increased.
  • Patent Document 1 by using a multi-hop path at the application level in which a relay site is inserted between the origin site that holds the content and the edge site that is the access destination of the client, A method for increasing the throughput is disclosed.
  • selection candidates that are two-hop paths are determined based on measurements such as Round Trip Time (hereinafter abbreviated as RTT), which is a delay caused by the round trip of packets between transmission and reception, and they are experimental from the direct paths.
  • RTT Round Trip Time
  • Non-Patent Document 1 discloses a technique for improving throughput by segmenting content data to be acquired and transferring it in parallel.
  • a client requests a file
  • an HTTP request including a newly assigned URI is transferred to the exit site assigned in advance by dividing the request into blocks at the entrance site.
  • the HTTP request with the range header for the original URI is transferred from the exit site to the origin site.
  • each block is transferred in parallel to the entrance site on a route passing through a plurality of exit sites, assembled at the entrance site, and transferred to the client.
  • the HTTP request and the HTTP response refer to those related to the GET method unless otherwise specified.
  • Non-Patent Document 2 shows a method of determining a global distribution tree that connects sites so that the bottleneck bandwidth of the overlay path between the sites is maximized. Unlike Patent Document 1 and Non-Patent Document 1 described above, since there is no limit on the number of hops, the throughput may be improved accordingly.
  • Non-Patent Document 3 in an overlay network on the Internet, a point-to-point overlay path connecting from one overlay node to another overlay node is dynamically set based on performance measurement between the overlay nodes. Is disclosed.
  • each block obtained by segmentation is substreamed in units of equal modulo, and a certain part (consisting of a plurality of blocks) of each substream is received as a unit and received from different peers.
  • TCP connection is terminated between the sites constituting the application level overlay network in order to transfer application data.
  • HTTP connection a TCP connection set for transferring HTTP data between a client, a proxy server, and an origin server is referred to as an HTTP connection here.
  • TCP Transmission Control Protocol
  • HTTP HyperText Transfer Protocol
  • server devices or end systems such as end user PCs without error.
  • data is received without error by receiving and processing a response of reception confirmation with respect to transmitted data.
  • the throughput depends on the RTT and the packet loss rate.
  • the RTT includes a round-trip propagation delay between transmission and reception, a packet protocol processing delay in the apparatus during the round-trip, a transfer delay on the line, and the like.
  • the same path is not always passed on the forward path and the return path.
  • the packet loss rate increases as the number of hops on the Internet increases between transmissions and receptions, and the RTT increases due to the propagation delay especially when links between ASs with submarine cables connecting different continents or islands are included. .
  • the throughput during data transfer by TCP decreases.
  • the window size that determines the upper limit of the amount of data that can be sent continuously without receiving response is dynamically changed according to how the receiving response is returned. This control is based on the Additive increase multiplicative decrease rule. Therefore, when it is determined that there is a packet loss, the window size at that time is halved, so the amount of data that can be transferred is halved.
  • Non-Patent Document 6 two methods can be considered to increase the throughput at the application level in consideration of the nature of TCP.
  • One is to reduce RTT in an application level relay device.
  • the maximum window size is W
  • the RTT of the link e and T e the throughput at the link
  • the W / T e the throughput of a certain path h is in the throughput of each link
  • the set of links included in the path h and E h can be calculated by min_ ⁇ e ⁇ E h ⁇ W / T e. Therefore, throughput can be maximized by selecting a path so that the maximum Te in the path is minimized.
  • Another method is to set the TCP connection between adjacent sites in parallel, if the number of connections is Z, a throughput of Z * W / T e. Also, if one packet loss is detected, if the maximum window size W is set to Z times for a TCP connection that is set to only one packet, the window size is reduced to Z * W / 2, but the TCP connection is If they are set in parallel, packet loss will be detected only in one connection, so the total maximum window size is W / 2 + (Z-1) * W, and the subtraction is ( Z-1) * W / 2. Therefore, it can be expected that the throughput increases as the parallel setting number Z increases.
  • Miyao “An optimal design scheme for global overlay networks withenhanced data transfer throughput,” ICC2010. D. G. Thaler, and C. V. Ravishankar, “Using name-based mappings toincrease hit rates,” IEEE / ACM Transactions on Networking vol. 6, No. 1, pp.1-14, February 1998. HTTP1.1, IETF RFC2616, June, 1999.http: //www.w3.org/Protocols/rfc2616/rfc2616.html http://en.wikipedia.org/wiki/Ajax_programming
  • the techniques disclosed in the above-described documents have the following problems.
  • the patent document 1 still has room for increasing the throughput between the origin site and the edge site. This is because the RTT is measured only from candidate sites that are relay sites, so that only one direction can be seen, and there is no control when there is a site with a large route asymmetry.
  • only a maximum of 2 hops is considered from the edge server to the origin server, and if the number of hops is allowed, RTT between sites may be suppressed and throughput may increase.
  • Non-Patent Document 2 a delivery route is optimized (beyond the limitation of 2 hops in Patent Document 1), but a specific method for dynamic optimization is not shown.
  • Non-Patent Document 3 dynamically sets a point-to-point overlay path, but does not support distribution to a plurality of sites. Moreover, it is necessary to perform the performance measurement for dynamic reconfiguration and the acquisition of the statistical values in separate procedures.
  • Patent Document 1 even if the point-to-point route between the edge server and the origin server can be dynamically set, it is not possible to set a route that efficiently distributes from the origin server to a plurality of edge servers. This is because, when selecting one of the two route candidates including the direct path to the origin site and the relay site, it cannot be used as a determination index whether the data desired in the relay site is cached.
  • Non-Patent Document 4 can increase the throughput by performing parallel division transfer, but does not cope with the situation where a plurality of servers are installed at the site to increase the capacity. This is because it is assumed that fouls are distributed among clients in a so-called peer-to-peer format.
  • Non-Patent Document 1 still has room to increase throughput. This is because a relay server is assigned to each divided block, but only in the second hop. Further, Non-Patent Document 1 has a problem that the processing load and necessary resources increase as the number of blocks increases. This is because it is necessary to set an HTTP connection each time a block is transferred, and the number of message processes for domain resolution increases.
  • Patent Document 1 Although already described as a problem of Non-Patent Document 4, technologies other than the above-mentioned Patent Document 1 cannot take into account an increase in capacity due to server clustering within the site.
  • an object of the present invention is to improve the throughput of data transfer between a plurality of server apparatuses distributed and arranged on a network, which is the above-described problem.
  • a data transfer system provides: An origin server in which content is accumulated, a plurality of proxy servers that transfer the requested content, and a domain resolution server that resolves the domain included in the identifier for the client to request data to the proxy server Multiple sites are connected over the network, The domain resolution server sets the measurement means for measuring the link parameters representing the communication status between the sites, and the routes for distributing the contents from the origin servers of the sites to the other sites based on the measurement results.
  • Route setting means, and assigning means for assigning a proxy server corresponding to the domain sets a domain resolution server installed at a parent site adjacent to the upstream side of the own site where the own domain resolution server is located on the own site on a route set for each origin server.
  • the allocating unit requests the parent domain resolution server to perform domain resolution based on the identifier to the proxy server that is a data transfer destination, and the proxy server of its own site requests a content request according to a response from the parent domain resolution server.
  • the proxy server in the parent site that is the destination of the transfer to the local site is notified to the proxy server in the local site, and a plurality of local proxy servers are sent to the local site in response to a request from the client or a domain resolution server in the child site adjacent downstream on the route. Assign the required proxy server from the installed proxy server and notify the domain resolution server at the client or child site, The structure is taken.
  • the domain resolution server is: A site in which an origin server in which content is accumulated, a plurality of proxy servers that transfer requested content, and a domain resolution server that resolves a domain included in an identifier for a client to request data to the proxy server Is the domain resolution server in the case where multiple are connected via a network, Measuring means for measuring each link parameter representing the communication status between the sites, route setting means for setting each route for delivering content from each origin server of each site to each other site based on this measurement result, Assigning means for assigning a proxy server corresponding to the domain, The route setting means sets a domain resolution server installed at a parent site adjacent to the upstream side of the own site where the own domain resolution server is located on the own site on a route set for each origin server.
  • the allocating unit requests the parent domain resolution server to perform domain resolution based on the identifier to the proxy server that is a data transfer destination, and the proxy server of its own site requests a content request according to a response from the parent domain resolution server.
  • the proxy server at the parent site, to which the server is to be transferred, is notified to the proxy server at the local site, and in response to a request from the domain resolution server at the child site or a downstream adjacent child site on the route Allocate the necessary proxy server from the proxy server installed in multiple, and notify the domain resolution server in the client or child site, The structure is taken.
  • the program which is the other form of this invention is: A site in which an origin server in which content is accumulated, a plurality of proxy servers that transfer requested content, and a domain resolution server that resolves a domain included in an identifier for a client to request data to the proxy server Is a program incorporated in the domain resolution server when a plurality of networks are connected via a network,
  • the domain resolution server is configured with measuring means for measuring link parameters representing the communication status between the sites, and each route for distributing content from each origin server at each site to each other site based on the measurement results.
  • the route setting means sets a domain resolution server installed at a parent site adjacent to the upstream side of the own site where the own domain resolution server is located on the own site on a route set for each origin server.
  • the allocating unit requests the parent domain resolution server to perform domain resolution based on the identifier to the proxy server that is a data transfer destination, and the proxy server of its own site requests a content request according to a response from the parent domain resolution server.
  • the proxy server at the parent site, to which the server is to be transferred, is notified to the proxy server at the local site, and in response to a request from the domain resolution server at the child site or a downstream adjacent child site on the route Allocate the necessary proxy server from the proxy server installed in multiple, and notify the domain resolution server in the client or child site, The structure is taken.
  • a data transfer method includes: An origin server in which content is accumulated, a plurality of proxy servers that transfer the requested content, and a domain resolution server that resolves the domain included in the identifier for the client to request data to the proxy server
  • a data transfer method in a data transfer system in which a plurality of sites are connected via a network The domain resolution server measures each link parameter representing the communication status between each site, and sets each route for delivering content from each origin server of each site to each other site based on the measurement result, Assign a proxy server corresponding to the domain, When the route is set, the domain resolution server installed at the parent site adjacent to the upstream side of the own site where the own domain resolution server is located on the route set for each origin server is installed at the own site.
  • a request for domain resolution based on the identifier to the proxy server of the data transfer destination is made to the parent domain resolution server, and the proxy server of its own site makes a content request according to a response from the parent domain resolution server.
  • the proxy server at the parent site which is the destination to be transferred, is notified to the proxy server at the local site, and the local server responds to the request from the domain resolution server at the child site adjacent downstream on the route.
  • the present invention is configured as described above, according to this, it is possible to improve the throughput of data transfer between a plurality of server computers distributed on the network.
  • FIG. 5 is an explanatory diagram showing a series of operations of domain resolution request / response message transfer and HTTP request / response data transfer as an example of the first embodiment.
  • FIG. 1 is a block diagram showing a configuration of a data transfer system according to Supplementary Note 1-1 of the present invention.
  • FIG. It is a block diagram which shows the structure of the data transfer system in attachment 2-1 of this invention.
  • FIGS. 1 to 5 are diagrams illustrating the configuration of the data transfer system
  • FIGS. 6 to 11 are diagrams illustrating the operation of the data transfer system.
  • the data transfer system includes clients 41 to 44 and a distribution system 22.
  • the distribution system 22 provides content posting and distribution services to the clients 41 to 44, and includes a plurality of sites 101 to 104 and a sub-network 18 connecting them.
  • the clients 41 to 44 are information processing terminals such as a personal computer operated by a predetermined user, and have a function of being guided to an appropriate site and uploading or downloading contents using HTTP. Further, the clients 41 to 44 exchange contents with the sites 101 to 104 through the same network as the sub-network 18 or independent of the sub-network 18.
  • the site 102 includes an origin server (OGS) 202, a domain resolution server 302 (DRS), proxy servers (PS) 503 to 505, a multilayer switch (MLS) 19, and an edge router 20. It is equipped with.
  • OGS origin server
  • DRS domain resolution server 302
  • PS proxy servers
  • MLS multilayer switch
  • the origin server (OGS) 202 accepts content uploads.
  • the domain resolution server (DRS) 302 resolves the address of the proxy server (PS) to which the content data request (HTTP request) is transferred, based on a request from the DRS of another site.
  • the edge router 20 performs connection between each device in the site and the sub-network at the IP level.
  • the MLS 19 connects the OGS 202, the PSs 503 to 505, the DRS 302, and the edge router 20.
  • the origin server 202 is one of a plurality of PSs in the next hop site for each different URI, on the premise of existing clients or proxy servers PS that request domain resolution of the destination PS for each domain.
  • the URI conversion as in Patent Document 2 is performed. If a domain resolution request can be made in units of URIs, this URI conversion is not necessary. That is, the OGS 202 stores content data newly uploaded from a content publisher in a storage device such as an HDD, and then assigns the following O-URI to the file.
  • Short.net indicates the entity providing this distribution service
  • site1 indicates the origin site to which this content is uploaded from the publisher
  • www is the host name as the origin server Is shown.
  • N sites for example, each site is indicated as site1, ..., siteN.
  • videocast indicates the name of the content providing service
  • channel3 indicates an individual channel
  • item2 indicates an individual distribution program
  • O domain subdomain corresponding to the site1.song.net origin site.
  • F domain f1578.site1.song.net The domain name after being converted to correspond to a different O-URI.
  • the O-URI is used as a link for acquiring data on the portal site, and when clicked, an HTTP request containing the O-URI is sent to the origin site, and the meta file used to acquire the program file from there. Data is downloaded to the client as an HTTP response.
  • O-URI http://www.site1.song.net/videocast/channel3/item2/ Edge site DRS address: 291.47.234.12, 291.47.234.13
  • F-URI http://f1578.site1.song.net/videocast/channel3/item2/
  • the DRS address installed at the edge site is the origin as the DRS address of the nearest edge site to which the client should be guided based on the IP address of the client at the timing when the client requests metadata.
  • the server decides.
  • two DRS addresses are described in consideration of a DRS failure.
  • the above metadata may be described in XML format.
  • a Web service that provides the state of a resource with a specified URI in XML format is called RESTful (see Non-Patent Document 7).
  • Patent Document 1 in order to allocate a cache server for each content of a different URI, hashing is performed on the original URI, a virtual server is allocated, and the original URI is included in the path portion. Before that, create a new URI by adding the domain of Akamai's virtual server.
  • the service operator since the service operator operates not only the distribution site but also the origin site, it is not necessary to embed the entire original URI in the path portion of the converted URI.
  • PS Proxy server
  • the proxy servers 503 to 505 cache or store the block received from the parent site PS, and prepare for the next request from another site.
  • the site closer to the route, that is, the upstream site is the parent site
  • the site farther from the route, that is, the downstream site is the child site, respectively. Call.
  • PS When PS receives an HTTP request, PS stores it as an HTTP response if it contains URI data. If it is not stored, in order to obtain the address of the PS assigned to the F domain in the DRS, a domain resolution request is made, and when it returns, the HTTP request is transferred to the address of the PS. When an HTTP response is returned for an HTTP request, the HTTP response is returned to the server that requested the URI.
  • Data transfer and storage in PS is based on the assumption that HTTP content data is handled on a memory with fast input / output.
  • performance is improved by using the data stored in the HDD that is slower to read than the memory in the OGS after being cached in the PS.
  • the domain resolution server (DRS) 302 includes a transmission device 14, a reception device 15, a data processing device 8, and a storage device 9.
  • the transmission device 14 and the reception device 15 exchange the domain resolution request / response message and the RTT statistical value request / response message with the DRSs of other sites, respectively.
  • the data processing device 8 includes a PS allocation unit 81 and a parent DRS determination unit 82 constructed by incorporating a program.
  • parent DRS refers to the DRS of the parent site to which the domain resolution request is to be transferred next.
  • parent site refers to a site closer to the route, that is, an upstream site, among two adjacent sites on the transfer path of the directed distribution tree generated as described later.
  • the parent DRS determination unit 82 determines the DRS address of the parent site to which the domain resolution request should be sent.
  • the PS allocation unit 81 (allocation means) determines the PS address to be allocated at its own site for each substream based on a request from the DRS at the child site.
  • the receiving device 15 passes the domain resolution response to the PS allocation unit 81 and the RTT statistical value response to the parent DRS determination unit 82.
  • the storage device 9 includes a local PS storage unit 91, a parent PS cache unit 92, a parent DRS storage unit 93, an RTT statistical matrix storage unit 94, an RTT statistical processing storage unit 95, and a distribution tree storage unit 96. It consists of.
  • the local PS storage unit 91 stores an entry composed of a combination of the PS address in the own site, the number of times-out, and the state.
  • the parent PS cache unit 92 has an entry including a combination of the F domain and the parent PS address received as a resolution response from the parent DRS as a table.
  • the parent DRS storage unit 93 stores the DRS address and the state of the parent site for itself in the directed distribution tree calculated by the parent DRS determination unit 82 and rooted at the origin site. Further, the TTL in the parent DRS storage unit 93 indicates the remaining time for which this information is valid, and this value decreases with the passage of time.
  • the feature of this table is that the transfer destination for domain resolution is written instead of the transfer destination of the HTTP request. In a normal system, a common parent PS is assigned regardless of the URI, but the parent DRS assigned in the present invention is different for each origin site.
  • the local PS storage unit 93 stores the address of each PS installed in the local site and its state.
  • the RTT matrix storage unit 94 statistical values obtained from the results of measuring the RTT from the site i to the site j a predetermined number of times are stored in a matrix.
  • the RTT statistical value from the other site to the local site is the value described in the RTT statistical value response received in response to the RTT statistical value response, and the value measured from the local site to the other site is the local site.
  • the RTT minimum values (see FIG. 5) in the table in the RTT statistics storage unit 95 are copied to the corresponding entries in the RTT matrix storage unit 94, respectively.
  • FIG. 4 is a diagram showing a table configuration of the parent DRS storage unit 93. This table is composed of the O domain, the DRS address of the origin site, the DRS address of the parent site, and the DRS status of the parent site.
  • the past measurement values of M RTTs are shifted to the left, TjM is deleted, the latest measurement value is written in the rightmost Ti1, and the past M times Update the minimum value of RTT. This process itself is performed by the parent DRS determination unit 82.
  • FIG. 6a shows a distribution tree when the RTT statistical value fluctuates while simultaneously measuring the RTT from the local site to the other site by receiving the RTT statistical value response to the transmission of the RTT statistical value request to the DRS of the other site. Shows the operation of reconfiguring. As described in Non-Patent Document 1, the distribution tree is for maximizing the throughput between the sites.
  • step S61 the parent DRS determination unit 82 of each site 101 or the like periodically transmits an RTT statistical value request to the DRS 302 or the like of all other sites 102 or the like.
  • This interval is an arbitrary interval set in advance, and is, for example, 15-30 minutes.
  • the timeout number N is set to zero.
  • the RTT statistical value request is an HTTP request having the following URI. http: // (request DRS address) / RTTstatistics
  • step S62 from the DRS j of the other site 102 etc. that sent the RTT statistics value request, RTT statistic vector ⁇ (DRS 1 , T 1 ), .., (DRS j-1 , T j-1 ,), (DRS j + 1 , T j + 1 ), ..., (DRS N , T N ) ⁇ (Where T k is the RTT statistic measured from DRS j to DRS k )
  • the RTT measurement value (the time from when the request is sent until the response arrives) is written in the RTT statistical storage unit 95 to update the statistical value and update it.
  • the RTT matrix storage unit 94 is further updated with the value.
  • the RTT statistical value response may be a vector in which the RTT statistical value vector is described in XML.
  • N increments a status indicating that it cannot be used is written in the state of the RTT statistics storage unit 95. Further, the RTT matrix storage unit 94 writes “unusable”. Then, RTT statistical values obtained from the responding site to all other sites in the RTT statistical value response message are written in the RTT matrix storage unit 94. This is done for all other sites that have issued RTT statistics requests.
  • a predetermined value for example, 3
  • RTT statistical values obtained from the responding site to all other sites in the RTT statistical value response message are written in the RTT matrix storage unit 94. This is done for all other sites that have issued RTT statistics requests.
  • step 63 referring to the RTT matrix storage unit 94, an optimal distribution tree in which each site is an origin site is calculated. If there is an O domain whose distribution tree is changed with reference to the distribution tree storage unit 96, the DRS of the parent site for the O domain is extracted, the parent DRS storage unit 93 is updated, and the parent PS cache unit In 92, the part corresponding to the changed distribution tree (identified by the O-domain) is cleared, and in the local PS address cache, all B-URI entries including the corresponding O domain are forced by the management procedure. Clear to step 61.
  • a method for specifying a parent DRS is, for example, a site closer to the root, that is, an upstream side in an adjacent site on the transfer path of a configured directed distribution tree.
  • the DRS of the site is identified as the parent DRS.
  • step 63 it is assumed that the DRS of each site already knows the DRS addresses of all other sites. This is realized, for example, when the management system that controls the entire system notifies the DRS address to all sites that are in operation every time a site is added or removed.
  • step 63 there is a method for maximizing the bottleneck (link with the smallest bandwidth) as described in Non-Patent Document 9. The purpose of this method is to maximize the transfer throughput between each site.
  • the throughput at the link e between the adjacent sites when there is no packet loss is given by W / Te , so the path between certain sites throughput on h, when the set E h of link e contained in h, given by the bottleneck on the path min_ ⁇ e ⁇ E h ⁇ W / T e. Therefore, if W is constant in each link, the throughput between each site can be maximized by applying the prim method, which is one of the procedures for creating the minimum spanning tree, using Te as the cost.
  • the prim method which is one of the procedures for creating the minimum spanning tree, using Te as the cost.
  • the proof is derived by referring to the method described in Non-Patent Document 10, but is omitted here. In this procedure, nodes are added to the subtree. Among the links that can be added to the subtree, the link with the smallest RTT statistical value stored in the RTT statistical matrix storage unit is added. Add the first node.
  • the virtual link means that the link from the site A to the site B is not a physical link but is realized by the transfer function of the Internet or a dedicated network. It can be said that the procedure for creating a distribution tree here is to extract an optimal directional distribution tree from a full mesh directed graph having N nodes and N (N-1) directed links.
  • an RTT statistical value is assigned to the cost of the edge from the site i to the site j. This is because it is desired to calculate the shortest path tree that minimizes the total sum of RTT on the link from each edge site to the origin site. This is a rough estimate of the time from when the client first issues an HTTP request for the file that the client wants to acquire to the edge site until the first time that the edge site receives an HTTP response, ignoring the domain resolution time within the site. It is. This so-called startup time is given by twice the sum of the RTT statistics at the virtual links between the sites on the path from each edge site to the origin site. For example, in FIG. 10 to be described later, this corresponds to the sum of the RTT statistics of the virtual links in S5, S6, S8, S10, S11, S13, S15, S16, S18, S23, S24, and S25. .
  • FIG. 6b shows the processing when an RTT statistical value request is received from a DRS at another site.
  • the RTT statistical value request is received from the DRS at the other site in step S65
  • the RTT statistical value related to each remote DRS stored in the RTT statistical storage unit 95 in step S66 is sent to the DRS that has been requested in the RTT statistical value response. Send and exit.
  • FIG. 7 a shows the domain resolution operation in the PS allocation unit 81. Messages related to domain resolution are exchanged with 1) the DRS of the client or child site, 2) the local PS, and 3) the DRS of the parent site, and the procedure is as follows.
  • step S71 if there is a domain resolution request of the parent PS for the F domain from the client or the local site proxy, in step S72, (1) if the F domain includes the same O domain as that of itself, the OGS is returned in the domain resolution response. Returns the address of. (2) If the F domain does not include the same O domain as the F domain, and the corresponding entry is in the parent PS cache unit 92, the domain resolution response is made. (3) When there is no corresponding entry, the parent DRS storage unit 93 is referred to and the parent DRS corresponding to the O domain is requested to resolve the parent PS address of the F domain.
  • the PS address assigned to the F domain is cached in the parent PS cache unit 92 in step S74, and the local PS requested to be resolved is received. Reply with the address assigned to.
  • the PS address corresponding to the F domain is determined by robust hashing with reference to the local PS storage unit 91 in step S76, and the resolution request It responds with the address to the child DRS that has finished and ends.
  • FIG. 7 b shows the local PS monitoring operation in the PS allocation unit 81.
  • step S77 after a fixed time has elapsed since the previous monitoring operation, the timeout count N is set to 0, and a ping is transmitted to each PS address in the local PS storage unit 91.
  • step S78 (1) when returning without time-out, the state of the PS is activated. (2) If timed out, increment N and send ping again. If the number of timeouts exceeds a certain number, the PS status is disabled. Then, the process returns to step B7.
  • step S76 The robust hashing in step S76 of FIG. 7a is performed based on the method described in Non-Patent Document 11 or Patent Document 3. This prevents the same content from being duplicated to multiple PSs as much as possible, but when a PS is added or removed, another PS is assigned to the F domain to which the existing PS is assigned. This is to minimize the ratio. If a server becomes unavailable, the child PS that has been transferred to it will make a resolution request to the child DRS, which will further request the parent DRS. Will be assigned.
  • the distribution tree having each site as a node is optimally configured without limiting the number of hops at the application level, the throughput at the application level is higher than when the number of hops is limited. Can be improved.
  • an optimal distribution tree is configured for each different origin site, so that it is possible to improve throughput regardless of the site from which content is acquired compared to the case where a fixed distribution tree is used regardless of the origin site. it can.
  • the distribution tree is created as a directed graph having the origin site as the root based on the RTT base measured between the sites, even if the asymmetry in the transfer state between the sites is large (for example, from site A to B) The difference between the RTT and the RTT from the site B to A is large), and the throughput can be further optimized.
  • FIGS. 8 and 9 show the operation of the parent DRS determination unit 82.
  • FIG. 8 shows an example of acquisition of RTT statistical information, RTT measurement, and creation of an RTT matrix in DRS1.
  • RTS1 sends RTT statistical information requests to DRS2, DRS3, and DRS4, RTT statistical information response is returned, and RTT is measured at the same time.
  • the RTT matrix storage unit 94 the RTT statistical information that has been responded from each DRS is written in the entry for which each DRS is the requesting side.
  • the measured value of RTT is written in the RTT statistics storage unit 95, and the RTT statistical value newly obtained as a result is written in the entry on the request side by itself (DRS1). That is, the RTT value measured as the time from when the RTT statistical information request is transmitted until the response is received is stored in the RSS statistical storage unit 95, and the result processed as the statistical value is written in the RTT matrix storage unit 94. It is.
  • FIG. 9 shows an operation example of creating a table of the parent DRS storage unit 93 based on the contents of the RTT matrix storage unit 94.
  • four directed distribution trees in which each DRS becomes an origin site are created.
  • the correspondence table of the parent DRS for each origin site in each DRS is as shown in FIG. 9, and this is incorporated in the parent DRS address storage unit 93. That is, in a site adjacent on the transfer path of the configured directed distribution tree, a site closer to the root, that is, a DRS of an upstream site is specified as a parent DRS (parent domain resolution server).
  • FIG. 10 shows an embodiment of a linkage operation for obtaining the data requested by the client to the origin site by the operation of the PS allocation unit 81.
  • the client has the F-URI of the data to be acquired and the address of the DRS 302 of the parent site 102 that should be used to resolve the PS from which the data is acquired in the metadata acquired from the OGS 204, and the HTTP request
  • a domain resolution request for the F domain included in the F-URI is transmitted to the DRS 302. (S1).
  • S1 DRS 302.
  • an HTTP request including the following URI may be used. http: // (DSR302 address) / PSes / f1578.site1.song.tv
  • the DRS 302 determines that the PS allocated in the site is PS502
  • the DRS 302 responds to the client with the address pqr1.s1 (S2).
  • This response may be an HTTP response including the following information described in XML format in the body. f1578.site1.song.tv pqr1.s1
  • the client 45 transmits an HTTP request to the PS 502 (S3).
  • the PS 502 receives the HTTP request, the PS 502 does not cache the data indicated by the URI. Therefore, the PS 502 issues a request to the local DRS 302 to resolve the F domain to the address of the parent PS to which the HTTP request is to be transferred (S4). This may be done with the DNS protocol.
  • the DRS 302 since the DRS 302 does not have a cache of the parent PS address for the corresponding F domain, the DRS 302 refers to the parent DRS storage unit 93 and sends a request for resolving the F domain to the DRS 301 that is the parent DRS corresponding to the O domain. (S5).
  • This may use an HTTP request containing the following URI: http: // (DSR302 address) /PSes/f1578.site1.song.tv
  • DRS301 allocates PS505, and resolves and responds to DRS302 with the address pqr2.s2 (S6).
  • This response may be an HTTP response including the following information described in XML format in the body. f1578.site1.song.tv pqr2.s2
  • Non-patent Document 7 A Web service that responds to the specified URI with the status of the resource as an XML file is called RESTful (Non-patent Document 7).
  • the DRS 302 that received the response sends a resolution response to the PS 502 that has requested the resolution in S4 (S7).
  • S7 resolution response to the PS 502 that has requested the resolution in S4
  • the resolution request in S4 is made using the DNS protocol
  • the solution response in S7 is also made using the DNS protocol.
  • the HTTP request is transferred to the ORG 204 (S21).
  • the ORG 204 returns the data designated by the F-URI to the PS 512 in the same site as an HTTP response (S22). This is further transferred to PS507, PS505, and PS502 (S23, S24, S25), and finally reaches the client 45 (S26).
  • FIG. 11 shows an example of a series of operations for preliminarily arranging data with high access frequency from the origin site to each site in advance.
  • the DRS of the origin site 104 issues a domain resolution request so that a PS is assigned to the URI of the content to be placed in the DRS of the site 102 that is the leaf site on the distribution tree (T1).
  • the “leaf site” refers to the topmost site in the directed distribution tree that does not have a transfer destination site.
  • the assigned PS When a resolution response is returned from the DRS of the site 102 (T2), the assigned PS is driven to issue an HTTP request for the URI for the content (T3). As a result, the PS in the site 102 transfers the HTTP request to the PS in the site 101 to be transferred next (T4).
  • the HTTP request is transferred from the site 102 on the distribution tree to the origin site 104 as T5 and T6. Based on this, data to be arranged from the origin site 104 reaches the site 102 via the sites 103 and 101 (T7, T8, T9).
  • the PSs in the sites 103 and 101 relay this data and simultaneously store this data as a function of the original PS.
  • FIG. 12 is a block diagram showing the configuration of DRS. As shown in this figure, the DRS according to this embodiment is different from FIG. 5 only in the data processing device 8 and includes a PS allocation unit 81 and a distribution tree calculation unit 82.
  • the distribution tree storage unit 96 entries of combinations of each site excluding the own site and its parent site are determined based on the distribution tree having the own site as a root, which is determined using the distribution tree calculation unit 83.
  • FIG. 13 is a flowchart showing an operation for creating a distribution tree of the route by the distribution tree calculation unit 83.
  • Steps S61 and S62 are the same as those in FIG. 6a described in the first embodiment.
  • Step S63 ' unlike step S63 of FIG. 6a, calculates only the directed distribution tree whose own site is the origin site. If the newly calculated distribution tree configuration is changed with reference to the distribution tree storage unit 96, the distribution tree storage unit 96 is updated, and another site whose parent DRS has been changed is determined therefrom. Then, the DRSs of all the sites with changes are notified of the new parent DRS, and the process returns to step S61. This notification may be performed using an HTTP PUT request.
  • FIG. 14 is a flowchart showing the operation of the PS allocation unit 81 relating to domain resolution in its own site. Only the functions added to FIG. 7a will be described here.
  • step S79 if there is a change in the parent DRS from the DRS of a certain origin site, the parent DRS storage unit 93 is updated in step S80, and the O domain (parent DRS) corresponding to the DRS of the origin site is updated in the parent PS cache unit 92. All F domain entries including the O domain are cleared by a management procedure in the local PS address cache.
  • each DRS calculates only the distribution tree that is the root of itself, and notifies all other DRSs of the updated parent DRS after the reconfiguration. Therefore, compared with the distributed first embodiment in which the DRS at each site independently creates the parent DRS table, the following effects are obtained. For one thing, the content of the parent DRS table held by each DRS does not match, so the time that the optimality of the HTTP transfer path is lost can be reduced. As a simple example of the loss of optimality, it is possible that the HTTP request returns to the same PS again because the path has changed before and after the reconstruction of the distribution tree. This can be detected if the PS finds its address listed in the X-Forwarded-For header.
  • the DRS of each site it is necessary for the DRS of each site to calculate all distribution trees whose root is the site of each DRS, whereas in this second embodiment, the self is the root. Since it is only necessary to calculate the distribution tree, the amount of calculation can be reduced.
  • the origin site DRS 304 notifies the combination of the O domain and the parent DRS to each DRS whose parent DRS has changed when the distribution tree is changed.
  • the parent DRS is notified to DRS 302, DRS 301, and DRS 303 by U1, U2, and U3. Since other operations are the same as those in FIG. 10, detailed description thereof is omitted.
  • the origin server OGS ⁇ b> 2 in this embodiment includes a transmission device 12, a reception device 13, a processing device 10, and a storage device 7.
  • the processing device 10 includes an issue processing unit 1001, a Web server processing unit 1002, and a client processing unit 1003, which are constructed by incorporating a program.
  • the Web server processing unit 1002 has a function of transmitting content data in response to an HTTP request received from a client, or creating stored data as HTML data and sending it out using HTTP.
  • substream data including a block group obtained by dividing content is distributed in parallel to a client to a plurality of PSs installed at the same site on the route.
  • the issuance processing unit 1001 is realized by a processing application such as assigning / converting a URI to the acquired data.
  • the client processing unit 1003 When the client processing unit 1003 receives a metadata request from the client from the Web server processing unit 1002, the client processing unit 1003 retrieves the corresponding metadata, refers to the geographic data storage unit 73 based on the client IP address, and searches for the nearest edge site. DRS is determined, added to the metadata, and passed to the Web server processing unit 1002.
  • the storage device 7 includes a block storage unit 71, a metadata storage unit 72, and a geographic data storage unit 73.
  • the block storage unit 71 stores uploaded content data.
  • the metadata storage unit 72 stores an O-URI, a B-URI expressed in a parametric manner, and metadata provided by an issuer.
  • the geographic data storage unit 73 stores the DRS address of each site and the range of IP addresses to which it corresponds.
  • the storage device 7 is realized by a storage server having a relatively large capacity, for example.
  • step S171 when the up-read data is delivered from the web server processing unit 1002, in step S172, the file is divided into one or a plurality of blocks, each is given a URI, and stored in the block storage unit 71. To do. Thereafter, in step S173, metadata is generated and integrated with the metadata from the issuer to create new metadata, which is given a URI and stored in the corresponding metadata storage unit 72.
  • each block does not necessarily have the same size.
  • a set of blocks transferred on the HTTP connection between the same PSs when the blocks are transferred in parallel is called substream data. That is, it can be said that the parallel transfer is simultaneously transferring a plurality of substreams each including a plurality of blocks (divided data) obtained by dividing the content.
  • the block ID (actually, block ID-1) is divided by the total number of substreams Z.
  • the remainder value (actually the remainder value +1) is used as the ID of the substream in which the block is arranged.
  • O-URI http://www.site1.song.net/videocast/channel3/item2/
  • “song.net” indicates the entity that provides this distribution service
  • site1 indicates the origin site to which this content has been uploaded from the publisher
  • www is the host name as the origin server Is shown.
  • each site is indicated as site1, ..., siteN.
  • videocast indicates the name of the content providing service
  • channel3 indicates an individual channel
  • item2 indicates an individual distribution program.
  • B-URI The URI given to the block obtained by segmenting this file is called a B-URI by adding a block number to the end of the O-URI.
  • B-URI http://www.site1.song.net/videocast/channel3/item2/block6
  • an HTTP request including a B-URI equivalent is forwarded to the PS on the relay route.
  • the B-URI is added.
  • an HTTP request including an O-URI equivalent is performed by the proxy first transferred from the client.
  • the B-URI is converted as follows so that a proxy server can be assigned in units of substreams in which PS is composed of a plurality of blocks in the same item. That is, (1) First, hash the O-URI (this value is assumed to be 1578 here), then add f1578 with f and then z3f1578 together with z3 with 3 substreams and z make. (2) Next, a domain s2 is created for substream ID 2 and substream total 3 for block ID 6. (3) Finally, the domain s2.z3f1578 combined with the above is replaced with www in the first B-URI.
  • the domain corresponding to the same file such as z3f1578.site1.song.net is called the F domain
  • the domain corresponding to different substreams of the same file such as s2.z3f1578.site1.song.net is the S domain. I will call it. If the client or PS can request domain resolution for each URI, unlike the existing one, the f1578 portion is not necessary.
  • the URI converted as described above is written in metadata used when the user obtains the target file, and stored in the metadata storage unit 72.
  • the parent DRS that has received this can immediately reproduce the three S domains from z3 and assign PSs to them.
  • These three combinations can be expressed as follows, for example. s1.z3f1578.site1.song.tv vwxy1 s2.z3f1578.site1.song.tv vwxy2 s3.z3f1578.site1.song.tv vwxy3
  • Non-patent Document 7 A Web service that responds to the specified URI with the state of the resource as an XML file is called RESTful (Non-patent Document 7).
  • the entire file is divided into three blocks, and the converted B-URI is http: //s1.z3f1578.site1. song.net/videocast/channel3/item2/block1 http://s2.z3f1578.site1.song.net/videocast/channel3/item2/block2 http://s3.z3f1578.site1.song.net/videocast/channel3/item2/block3
  • the OGS creates the following metadata and stores it in the metadata storage unit 72. This is accessed from the client with an HTTP request containing an O-URI.
  • O-URI http://www.site1.song.net/videocast/channel3/item2/ Edge site DRS address: 291.47.234.12, 291.47.234.13
  • the amount of information increases when the total number of blocks is large.
  • a parametric expression is used for each substream. Is used.
  • the DRS address of the edge site to which the client should be guided is determined based on the IP address of the client when the client requests metadata.
  • two DRS addresses at the optimum edge site determined in consideration of a DRS failure are described.
  • the DRS address of the destination edge site is determined by referring to the geographic data storage unit 73 and the client IP address in step S176.
  • the B-URI group corresponding to the request O-URI and the metadata described by the issuer are extracted from the metadata storage unit, the DRS address is further written, passed to the Web server processing unit 1002, and the process ends.
  • DRS Domain resolution server
  • FIG. 18 shows a table configuration of the parent PS cache unit of the DRS.
  • an entry including a combination of each S domain and the parent PS address for the same F domain is included. Have.
  • the operation of DRS will be described.
  • the operation of the parent DRS determination unit is the same as in FIG.
  • the operation of the distribution tree calculation unit is the same as that in FIG.
  • the operation of the PS allocation unit 81 when the distribution tree is reconstructed in a distributed manner will be described with reference to FIGS. 19a, b, and c.
  • FIG. 19a is a flowchart showing the operation when there is a domain resolution request for the S domain from the client or the local PS. If there is a resolution request from the client F domain to the parent PS address in step S191, in step S192, (1) an address in the parent PS cache unit is returned to each S domain, and (2) if there is none, all S Assign a local PS to the domain and respond.
  • step S193 if there is a request for resolving the parent PS address for the S domain from the local PS, (1) If the S domain includes the same O domain as the S domain, the OGS address is returned in the address resolution response. (2) If not included, the address in the parent PS cache part is returned, and if not (3), the parent DRS storage part is referred to, and the parent DRS corresponding to the O domain is transferred to the parent PS address from the F domain. Send a resolution request.
  • the domain resolution request and response from the local PS is performed using the existing DNS protocol.
  • FIG. 19B is a flowchart showing the operation in the PS allocation unit 81 when there is a domain resolution response from the DRS at the parent site or when there is a domain resolution request for all S domains from the DRS at the child site. .
  • the PS address assigned to the S domain is cached in the parent PS cache unit in step S196, and the local PS that requested the resolution is Respond with the assigned address. If there is a domain resolution request for all S domains from the child site DRS in step S197, the PS address group corresponding to each S domain is determined by robust hashing with reference to the local PS storage unit in step S198 and resolved. Return the address to the requesting child DRS and exit.
  • step S198 is performed based on the method of Non-Patent Document 11 or Patent Document 3. This prevents the same content from being duplicated to multiple PSs as much as possible, but when a PS is added or removed, another PS is assigned to the S domain to which the existing PS is assigned. This is to minimize the ratio.
  • FIG. 19 c shows the local PS monitoring operation in the PS allocation unit 81.
  • step S199 after a predetermined time has elapsed since the previous monitoring operation, the timeout count N is set to 0, and a ping is transmitted to each PS address in the local PS storage unit. If the process returns without time-out in step S200, the state of the PS is activated. If timed out, increment N and send ping again. If the number of timeouts exceeds a certain number, the PS status is disabled. Then, the process returns to step S199.
  • each PS at the local site uses the DRS of the local site to resolve the PS address of the parent site on a substream basis.
  • a single HTTP persistent connection is established for the address of the resolved parent PS, and for each block in the same substream, the same connection is pipelined, that is, in B-URI.
  • HTTP requests are issued in the order of increasing block numbers, and block data is acquired by HTTP responses.
  • Non-Patent Document 12 describes persistent connections and pipe lining.
  • the client 41 includes a transmission device 22, a reception device 23, a data processing device 24, a storage device 11, an input device 25, and an output device 21.
  • the input device 25 and the output device 21 are used by the user, and are, for example, a keyboard and a liquid crystal display, respectively.
  • the data processing device 24 includes a reproduction processing unit 2402, a display processing unit 2401, and a background processing unit 2403.
  • the display processing unit 2401 changes the display based on the input signal from the user input device 25, processes the data received from the reproduction processing unit 2402, and passes it to the output device 21.
  • the background processing unit 2403 transmits / receives data according to an instruction from the display processing unit 2401 through the transmission / reception device. For this purpose, domain resolution is also performed with the DRS at the edge site. Note that the background processing unit 2403 and the display processing unit 2401 are included in the main functions of the Web browser.
  • the storage device 11 includes a block storage unit 1101 and a metadata storage unit 1102.
  • the display processing unit 2401 acquires the metadata from the OGS
  • the display processing unit 2401 stores the metadata in the metadata storage unit 1102 and instructs the background processing unit 2403 to acquire the content.
  • FIG. 21 is a flowchart for explaining the subsequent operation of the background processing unit 2403 of the client.
  • the metadata is extracted from the metadata storage unit 1102 in step S212, and all S in the parametric URI group described in the metadata file are extracted. Perform PS domain resolution for all domains.
  • step S213 a persistent HTTP connection is set for each PS whose domain has been resolved, and an HTTP request for a different block belonging to the same substream is transferred in a pipeline format and terminated.
  • block data When block data is received as an HTTP response related to B-URI in step S214, it is stored in the block storage unit 1101 in step S215. If the acquired block is the first block with respect to the F domain in step S216, the playback processing unit 2402 is instructed to start playback.
  • domain resolution is performed in units of substreams. Therefore, domains are identified in units of blocks (here identified by B-URI). The number of messages required for domain resolution can be reduced as compared with the case of performing resolution.
  • domain resolution for assigning PSs to each substream is performed collectively, the number of messages required for domain resolution can be reduced as compared with the case where it is performed for each substream.
  • Non-Patent Document 1 it is possible to reduce processing addition and setting delay as compared with the case where PS sets an HTTP connection in units of blocks.
  • FIG. 22 shows an operation example of domain resolution.
  • the top page accessed by the client has a link to metadata information. This has an O-URI.
  • metadata B-URI in each substream is parametrically expressed
  • a javascript program for realizing the background processing unit 2403 described above are downloaded from OGS (T1).
  • Javascript which is a program that runs on the client's Web browser, is described in Non-Patent Document 13.
  • the PS allocation unit of the DRS 302 issues an F domain resolution request to the parent site DRS 301 at the timing when one of the domain resolution requests of T6, T7, and T8 is first received (T9).
  • DRS301 responds to DRS302 with the addresses of PS501, PS502, and PS503 for each domain including s1, s2, and s3 (T10), it resolves with the addresses of PS corresponding to PS501, PS502, and PS503, respectively. It responds (T11, T12, T13).
  • These PSs establish a persistent connection for the received parent PS, and send HTTP requests containing B-URIs with substream IDs s1, s2, and s3, respectively, in HTTP 1.1 pipeline format. (T14, T15, T16).
  • FIG. 23 is an explanatory diagram showing the parallel transfer status of substreams and the order of block numbers in the substreams.
  • the blocks transferred in each substream and their order are s1: block1, block4, block7, .... s2: block2, block5, block8, .... s3: block3, block6, block9, .... It becomes.
  • PS assigned to st1, st2, st3 at origin site 103 are 507, 508, 509.
  • PSs assigned to st1, st2, and st3 at relay site 101 are 501, 502, and 503.
  • PSs assigned to st1, st2, and st3 at the edge site 102 are 504, 505, and 506.
  • the blocks received by the background processing unit from each connection in a round robin manner inside the client 46 are assembled and reproduced in order by the reproduction processing unit in the client.
  • the origin site 103 distributes substream data composed of blocks obtained by dividing content to a plurality of PSs installed at the same site on the route, the throughput is increased. Can be further improved.
  • a plurality of substream data is transferred in parallel to a plurality of PSs on the same site according to a route based on the directed distribution tree set in the domain resolution server.
  • a plurality of substream data may be transferred in parallel to a plurality of PSs on the same site according to a preset route.
  • the transfer network has a configuration in which high-speed transfer is performed using a substream that is a multiple of that number. Has characteristics.
  • FIG. 24 is a diagram for explaining the structure of the site.
  • conversion servers relay servers 2301 and 2302 (hereinafter referred to as “TS”) are newly added to the site.
  • TS conversion servers
  • These conversion servers 2301 and 2302 directly exchange data with clients having a limited number of connection settings, and also exchange data by setting an HTTP connection with a PS in the same site.
  • the TS performs substream replacement.
  • the substream data is transmitted / received to / from the PS with a predetermined number of sessions, and for the client, the substream data is within the range of the maximum number of sessions that the client can connect to.
  • a function transfer means that aggregates and transfers them to the client.
  • TS does not cache blocks that can be distinguished by URI. It is assumed that different IP addresses are assigned to TS and PS, and DRS 302 can distinguish TS and PS by looking at the source address of the transmitted data.
  • FIG. 25 is a flowchart showing the operation of the PS allocation unit of the DRS 302. Here, a different part from 3rd Embodiment is demonstrated.
  • FIG. 19a is modified as follows.
  • step S251 if an F domain resolution request is received from the client as an HTTP request, in step S252, a TS is assigned to each of all applicable S domains, and the address is returned. However, the address of the different TS should be less than the maximum number of client connection settings.
  • step S253 If there is an S domain resolution request from the TS in step S253, if the local PS allocated to the corresponding S domain is in the local PS cache unit in step S254, it is responded, and if not, all of the local PSs are robust hashing. Allocate a local PS for the S domain and respond with its address.
  • step S255 if there is a resolution request from the local PS for the S domain, in step S256, a response is made by referring to (1) (2) the parent PS cache unit, and (3) if there is none, corresponds to the O domain.
  • the parent DRS is requested to resolve the parent PS domain for all S domains.
  • the TS performs the same operation as the PS, but the PS may cache the data when the HTTP response returns, but the TS does not cache.
  • step S256 is performed based on the method of Non-Patent Document 11 or Patent Document 3. This prevents the same content from being duplicated to multiple PSs as much as possible, but when a PS is added or removed, another PS is assigned to the S domain to which the existing PS is assigned. This is to minimize the ratio.
  • a TS for transposing a substream is inserted between the PS and the client. Therefore, even if the client has an upper limit on the number of HTTP connection settings, it is independent of this. In the distribution network, the total number of substreams transferred in parallel can be set to improve the throughput.
  • FIG. 26 is a diagram showing a cooperative operation among the client 45, the DRS 302, the TS TS 2301, 2302, and the PSs 501 to 506.
  • the HTTP connection that can be terminated by the client is “2”
  • the TS server replaces the substream so that the total number of substreams is “6” and parallel transfer is performed.
  • a substream whose ID is n is abbreviated as ssn.
  • the client requests the FRS resolution to the DRS 302 specified in the metadata with the upper limit of connection number “2”
  • the address of TS2301 is used for ss1, ss2, and ss3, and the address of TS2302 is used for ss4, ss5, and ss6.
  • a resolution response is received.
  • the client sets a persistent connection in TS2301 and TS2302, respectively, and transmits an HTTP request including a URI (B-URI) of a block belonging to ss1, ss2, ss3 and ss4, ss5, ss6 in a pipeline format.
  • URI URI
  • TS2301, block1, block2, block3, block7, block8, block9 HTTP requests including the corresponding B-URIs are sent to the TS 2301 in that order.
  • TS2302 has block4, block5, block6, block10, block11, block12, ... Are sent to the TS 2302 in that order.
  • the TS 2301 Upon receiving these B-URIs including the substream IDs of ss1, ss2, and ss3 for the first time, the TS 2301 transfers a resolution request for each S domain to the DRS 302. Similarly, the TS 2302 transfers the resolution request for each S domain to the DRS 35. These requests are made using the DNS protocol.
  • the DRS 302 responds to the TS 2301 by allocating PS501, PS502, and PS502 to the S domain resolution requests regarding ss1, ss2, and ss3. Further, it is assumed that the DRS 302 responds to the TS 2302 by assigning PS 504, PS 505, and PS 506 to each S domain resolution request for ss4, ss5, and ss6. Then, TS2301 sets up a persistent connection for PS501, PS502, and PS503, and transfers a request including a B-URI corresponding to each S domain onto each corresponding persistent connection.
  • the TS 2302 sets a persistent connection for each of the PS 504, PS 505, and PS 506, and transfers a request including a B-URI corresponding to each domain onto each corresponding persistent connection. If the PS holds data, it returns a block to the TS. If not, the PS requests the DRS to resolve the domain of the parent site PS.
  • the program is stored in a storage device or recorded on a computer-readable recording medium.
  • the recording medium is a portable medium such as a flexible disk, an optical disk, a magneto-optical disk, and a semiconductor memory.
  • the domain resolution server 5030 measures each link parameter representing the communication status between each site, and each route for delivering content from each origin server of each site to each other site based on the measurement result
  • the route setting means 5032 sets the domain resolution server installed at the parent site adjacent upstream of the own site where the own domain resolution server is located on the route set for each origin server to the own site.
  • the allocating unit 5033 requests the parent domain resolution server to perform domain resolution based on the identifier to the proxy server that is a data transfer destination, and the proxy server of its own site sets the content according to a response from the parent domain resolution server.
  • the proxy server in the parent site to which the request is to be forwarded is notified to the proxy server in the local site, and the local server responds to the request from the domain resolution server in the child site adjacent downstream on the route.
  • Appendix 1-2 A data transfer system according to appendix 1-1, The measuring means measures the communication status between the domain resolution servers that distinguish the data transmission / reception directions between the domain resolution servers installed at each site as a link parameter representing the communication status between the sites. Data transfer system.
  • Appendix 1-3 A data transfer system according to appendix 1-2, The measuring means measures the round trip time between the domain resolution servers installed at the sites as the link parameter, The route determination means sets a route that minimizes the maximum value of round trip times between the sites on each route. Data transfer system.
  • appendix 1-4 A data transfer system according to appendix 1-2, The measurement means measures the round trip time between each domain resolution server installed in each site as the link parameter, The route determination means sets a route that minimizes the sum of round trip times between the sites on each route. Data transfer system.
  • the measuring unit of the domain resolution server measures the link parameter between the domain resolution server that is self and another domain resolution server with respect to another domain resolution server, and at the time of the measurement, Request and obtain the measurement result already measured by the other domain resolution server from the resolution server, Data transfer system.
  • Appendix 1-6 A data transfer system according to any one of appendices 1-1 to 1-5, The measurement unit and the path setting unit included in the domain resolution server operate at a preset timing to set a path and a parent domain resolution server. Data transfer system.
  • Appendix 1--7 A data transfer system according to any one of appendices 1-1 to 1-6, The route setting means provided in each domain resolution server of each site determines a route for delivering the content stored in the origin server of its own site, determines the parent domain resolution server, Notify the domain resolution server, and the other domain resolution server sets a parent domain resolution server based on it, Data transfer system.
  • a site in which an origin server in which content is accumulated, a plurality of proxy servers that transfer requested content, and a domain resolution server that resolves a domain included in an identifier for a client to request data to the proxy server Is the domain resolution server in the case where multiple are connected via a network, Measuring means for measuring each link parameter representing the communication status between the sites, route setting means for setting each route for delivering content from each origin server of each site to each other site based on this measurement result, Assigning means for assigning a proxy server corresponding to the domain, The route setting means sets a domain resolution server installed at a parent site adjacent to the upstream side of the own site where the own domain resolution server is located on the own site on a route set for each origin server.
  • the allocating unit requests the parent domain resolution server to perform domain resolution based on the identifier to the proxy server that is a data transfer destination, and the proxy server of its own site requests a content request according to a response from the parent domain resolution server.
  • the proxy server at the parent site, to which the server is to be transferred, is notified to the proxy server at the local site, and in response to a request from the domain resolution server at the child site or a downstream adjacent child site on the route Allocate the necessary proxy server from the proxy server installed in multiple, and notify the domain resolution server in the client or child site, Domain resolution server.
  • the domain resolution server described in appendix 1-8 The measuring means measures the communication status between the domain resolution servers that distinguish the data transmission / reception directions between the domain resolution servers set at each site as a link parameter representing the communication status between the sites. Domain resolution server.
  • a site in which an origin server in which content is accumulated, a plurality of proxy servers that transfer requested content, and a domain resolution server that resolves a domain included in an identifier for a client to request data to the proxy server Is a program incorporated in the domain resolution server when a plurality of networks are connected via a network
  • the domain resolution server is configured with measuring means for measuring link parameters representing the communication status between the sites, and each route for distributing content from each origin server at each site to each other site based on the measurement results.
  • the route setting means sets a domain resolution server installed at a parent site adjacent to the upstream side of the own site where the own domain resolution server is located on the own site on a route set for each origin server.
  • the allocating unit requests the parent domain resolution server to perform domain resolution based on the identifier to the proxy server that is a data transfer destination, and the proxy server of its own site requests a content request according to a response from the parent domain resolution server.
  • the proxy server at the parent site, to which the server is to be transferred, is notified to the proxy server at the local site, and in response to a request from the domain resolution server at the child site or a downstream adjacent child site on the route Allocate the necessary proxy server from the proxy server installed in multiple, and notify the domain resolution server in the client or child site, program.
  • the measuring means measures the communication status between the domain resolution servers that distinguish the data transmission / reception directions between the domain resolution servers set at each site as a link parameter representing the communication status between the sites. program.
  • An origin server in which content is accumulated, a plurality of proxy servers that transfer the requested content, and a domain resolution server that resolves the domain included in the identifier for the client to request data to the proxy server A data transfer method in a data transfer system in which a plurality of sites are connected via a network, The domain resolution server measures each link parameter representing the communication status between each site, and sets each route for delivering content from each origin server of each site to each other site based on the measurement result, Assign a proxy server corresponding to the domain, When the route is set, the domain resolution server installed at the parent site adjacent to the upstream side of the own site where the own domain resolution server is located on the route set for each origin server is installed at the own site.
  • a request for domain resolution based on the identifier to the proxy server of the data transfer destination is made to the parent domain resolution server, and the proxy server at its own site makes a content request according to a response from the parent domain resolution server.
  • the proxy server at the parent site which is the destination to be transferred, is notified to the proxy server at the local site, and the local server responds to the request from the domain resolution server at the child site adjacent downstream on the route.
  • Appendix 1-13 A data transfer method according to appendix 1-12, When measuring the link parameter, the communication status between the domain resolution servers that distinguishes the data transmission / reception directions between the domain resolution servers set at each site is measured as a link parameter that represents the communication status between the sites. To Data transfer method.
  • the origin server 7010 includes a content processing unit 7011 that holds content in units of blocks that can be divided and gives an identifier including a domain that identifies each substream including one or more blocks to the block.
  • the domain resolution server 7030 includes an assigning unit 7031 that determines a proxy server to be assigned for each domain that identifies each substream.
  • the allocating unit 7031 is configured such that the domain of one substream from the proxy server of the local site where the local domain resolution server is arranged, on the upstream side on the route from the site where the origin server is located to the edge site accessed by the client
  • the parent site domain resolution server requests the parent site for each of all the substreams constituting the original content of the one substream. Make a domain resolution request to assign a proxy server in Data transfer system.
  • Appendix 2-2 A data transfer system according to appendix 2-1, The content processing means included in the origin server assigns each block with an identification number corresponding to the order in which the content that is the source of the block is reproduced, and sets the identification number of the divided data to the substream. An identifier including the same domain of the substream is assigned to blocks having the same remainder value divided by the total number of Data transfer system.
  • Appendix 2-3 A data transfer system according to appendix 2-1 or 2-2, The content processing means included in the origin server gives the identifier including the total number of the substreams to the block. Data transfer system.
  • Appendix 2-4 A data transfer system according to any one of appendices 2-1 to 2-3, In the edge site accessed by the client, a relay server for transferring the content is provided between the client and the proxy server, The domain resolution server allocation means allocates a relay server within the upper limit of the number of connections that can be set by the client to the domain resolution request of the client. Data transfer system.
  • the origin server in a data transfer system in which a plurality of sites are connected via a network, Content processing means for holding content in units of blocks that can be divided and providing the block with an identifier including a domain that identifies each substream in which one or more of the blocks are included;
  • the content processing means assigns each block with an identification number corresponding to the order in which the content that is the source of each block is reproduced, and a remainder obtained by dividing the identification number of the divided data by the total number of substreams
  • An identifier including a domain corresponding to the same substream is assigned to blocks having the same value of Origin server.
  • An origin server in which content is accumulated, a plurality of proxy servers that transfer the requested content, and a domain resolution server that resolves the domain included in the identifier for the client to request data to the proxy server A program incorporated in the origin server in a data transfer system in which a plurality of sites are connected via a network, The origin server stores content in units of blocks that can be divided, and realizes a content processing unit that assigns an identifier including a domain that identifies each substream including one or a plurality of blocks to the block.
  • the content processing means assigns each block with an identification number corresponding to the order in which the content that is the source of each block is reproduced, and a remainder obtained by dividing the identification number of the divided data by the total number of substreams
  • An identifier including a domain corresponding to the same substream is assigned to blocks having the same value of program.
  • the domain resolution server in a data transfer system in which a plurality of sites are connected via a network,
  • an identifier including a domain for identifying each substream including one or a plurality of the blocks is given to a block obtained by dividing the content
  • the allocating unit assigns a domain corresponding to one substream from the proxy server of the local site where the local domain resolution server is arranged on a given route from a site where the origin server is accessed to an edge site accessed by a client.
  • the parent site domain resolution server makes the parent for each of all the substreams constituting the content that is the source of the one substream.
  • An origin server in which content is accumulated, a plurality of proxy servers that transfer the requested content, and a domain resolution server that resolves the domain included in the identifier for the client to request data to the proxy server A program incorporated in the domain resolution server in a data transfer system in which a plurality of sites are connected via a network,
  • an identifier including a domain for identifying each substream including one or a plurality of the blocks is given to a block obtained by dividing the content
  • An allocation unit for determining a proxy server to be allocated to each domain for identifying the substream is realized in the domain resolution server,
  • the allocating unit assigns a domain corresponding to one substream from the proxy server of the local site where the local domain resolution server is arranged on a given route from a site where the origin server is accessed to an edge site accessed by a client.
  • the parent site domain resolution server makes the parent for each of all the substreams constituting the content that is the source of the one substream. Make a domain resolution request to assign a proxy server at the site, program.
  • An origin server in which content is accumulated, a plurality of proxy servers that transfer the requested content, and a domain resolution server that resolves the domain included in the identifier for the client to request data to the proxy server A data transfer method in a data transfer system in which a plurality of sites are connected via a network, The origin server holds the content in units of blocks that can be divided, and gives the block an identifier including a domain that identifies each substream including one or more of the blocks, The domain resolution server determines a proxy server to be assigned for each domain identifying each substream; When assigning a proxy server by the domain resolution server, a route from the proxy server of the local site where the local domain resolution server is located to a domain of one substream to a site accessed by the client from the site where the origin server is located In the above, when a request is made to resolve to the proxy server of the parent site adjacent to the upstream side, the domain resolution server of the parent site sends to each of all the substreams constituting the content that is the
  • Appendix 2-11 A data transfer method according to appendix 2-10, When the origin server assigns an identifier to the block, each block is assigned an identification number corresponding to the order in which the content that is the source of the block is reproduced, and the identification number of the divided data is An identifier including the same domain of the substream is assigned to blocks having the same remainder value divided by the total number of substreams. Data transfer method.
  • the present invention is a content data distribution service or application data distribution from a plurality of server sites or data centers that are geographically distributed on the Internet, which is composed of a large number of network operation units. It can be applied to uses such as services.
  • not only the content distribution from the origin site to the edge site but also the result processed by the OGS application is transferred to the end user's Web client via one or more relay sites. It can also be used for application distribution.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

　ドメイン解決サーバが、各サイト間における通信状況を計測する計測手段と、計測結果に基づいてコンテンツを配信する各経路を設定する経路設定手段と、ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を備え、経路設定手段は、経路上において、自サイトよりも上流に隣接する親サイトのドメイン解決サーバを親ドメイン解決サーバとして設定し、割り当て手段は、親ドメイン解決サーバに、識別子に基づくドメイン解決の要求を行うと共に、その応答に従って、コンテンツ要求を転送すべき先である親サイトにあるプロキシサーバを自サイトのプロキシサーバに通知し、クライアントもしくは子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置されたプロキシサーバから必要となるプロキシサーバを割り当て、通知する、という構成を採る。

Description

データ転送システム
　本発明は、データ転送システムにかかり、特に、ネットワーク上に分散配置された複数のコンピュータ間でデータを転送するシステムに関する。
　インターネットにおいては、地理的に分散配置された各サイト間でデータ転送が行われている。近年、コンピュータの普及、及び、ネットワーク技術の発達により、各サイト間で送受信されるデータ転送量は増大して来ている。このため、データ転送量が増大しても高速にデータ転送できることが望まれる。
　ここで、例えば、図１に示すようなデータ転送システムを考える。図１に示すデータ転送システムは、クライアント装置４１～４４と、分配システム２２と、から構成されている。分配システム２２は、クライアント装置４１～４４に対してコンテンツの投稿、配信などの種々のサービスを行なうもので、複数のサイト１０１～１０４とそれらをつなぐサブネットワーク１８とからなる。
　ここで、上述したサイト１０１～１０４とは、例えば、図２の符号１０２に示すように、データを処理、もしくは蓄積できるサーバ装置（ＯＧＳ２０２，ＤＲＳ３０２，ＰＳ５０３，５０４，５０５）を１つもしくは複数設置する場所を指すものとする。そして、サーバ装置は、マルチレイヤスイッチ１９によって、インターネットにアクセスするために位置するエッジルータ２０とつながる。
　上記サイトを識別する具体的な方法としては、都市、もしくは、国がある。また、サイトの設置形態としては、サーバ装置をラックに格納してビル内のフロアーに設置するような小型のものから、巨大数のサーバ装置群を専用に収容するインターネットデータセンター（iDC）まである。
　サイト間でデータの高速な転送が必要とされる具体的な例は、特許文献２にあるようなCDN（Contents Delivery Network：コンテンツ配信網）にいくつか見られる。まず、CDNにおいて、コンテンツホルダーから発行されたWebサイトや動画等のコンテンツデータがホスティングされているサイト（オリジンサイトとも呼ぶ）から、エンドユーザへの配信を行うエッジサイトへデータを複製する場合がある。そして、CDNにおける別の例としては、コンテンツユーザがアクセスしたエッジサイトに、期限が有効な所望のコンテンツがキャッシュされていない場合、上記オリジンサイトからエッジサイトへコンテンツデータを転送する場合がある。更に、別の例としては、オリジンサイトで動的に生成されるようなそもそもキャッシュ不能なデータを、オリジンサイトからエンドユーザがアクセスしたエッジサイトに転送する場合がある。これらのすべての例においては、オリジンサイトからエッジサイトにデータを高速に転送することができれば、エンドユーザの体感や満足度が高めることができる。
　一方で、上述したCDNでは、アクセス頻度の高いものに対してはキャッシュすることで効果を上げてきたが、ロングテールのようにアクセス頻度が極めて低いがそうしたコンテンツが多数ある場合は、もはやキャッシュは有効ではない。つまり、そのようなコンテンツに最初にユーザがアクセスしたエッジサイトでは、ほとんどがオリジンサイトまでコンテンツデータを取りにいく必要が生じる。
　よってユーザ体感を上げるためには、オリジンサイトからエッジサイトに高速にデータを転送する必要が出てくる。
　ここで、特許文献１では、コンテンツを保持しているオリジンサイトと、クライアントのアクセス先であるエッジサイトと、の間に中継サイトを入れた、アプリケーションレベルでのマルチホップなパスを用いることで、スループットを高めようとする方法を開示している。ここでは、送受信間でのパケットの往復でかかった遅延であるRound Trip Time（以降RTTと省略）等の計測に基づいて２ホップパスである選択候補を決定し、それらと直通パスのなかから試験的なデータのダウンロードに基づいて最適なパスを選ぶ。
　また、非特許文献１では、取得したいコンテンツのデータをセグメント化して並列転送させることでスループットを向上させようとする技術を開示している。ここでは、あるクライアントがファイルを要求すると、その入口サイトで要求をブロック毎にわけて新たに付与したURIを含むHTTPリクエストを、予め割当てられた出口サイトに転送する。そして出口サイトからはもとのURIに対するレインジヘッダをもつHTTPリクエストをオリジンサイトに転送する。こうしてHTTPレスポンスとして、各ブロックは複数の出口サイトを経由する経路上を入口サイトまで並列に転送され、入口サイトで組み立てられてクライアントまで転送される。なお、以下では、HTTPリクエストおよびHTTPレスポンスは、特に断りのない限り、ＧＥＴメソッドに関するものを指すものとする。
　また、非特許文献２では、各サイトをつなぐ全域分配木を、各サイト間のオーバレイパスのボトルネック帯域が最大になるように決定する方法が示されている。上述した特許文献１や非特許文献１とは異なり、ホップ数の制限がないので、その分スループットを向上させる可能性がある。
　また、非特許文献３では、インターネット上でのオーバレイ網において、あるオーバレイノードから別のオーバレイノードへつながるポイントツーポイントのオーバレイパスを、各オーバレイノード間の性能測定に基づいて動的に設定することが開示されている。
　また、非特許文献４では、セグメント化して得られる各ブロックをモジュロが等しい単位でサブストリーム化し、各サブストリームのある部分（複数のブロックからなる）を単位として、それを異なるピアから受信して一旦組立て、また別のピアにサブストリームのある部分を提供することで、ストリーミングサービスを非常に多くのピアに同時に提供することを実現している。
　上述した技術は、いずれもインターネットの上にアプリケーションレベルのネットワークをオーバレイして設置し、アプリケーションレベルのスループットを増大させることを狙いとしている。
　ここで、アプリケーションレベルのオーバレイネットワークを構成する各サイト間では、アプリケーションデータを転送するためにTCPコネクションが終端される。アプリケーションレベルのスループットを制御するには、TCPの性質について把握しておく必要がある。以降、クライアント、プロキシサーバ、オリジンサーバの間で、HTTPデータを転送するために設定されるTCPコネクションを、ここではHTTPコネクションと呼ぶことにする。
　サーバ装置、あるいはエンドユーザのPCのようなエンドシステム間でHTTP（HyperText Transfer Protocol）のようなアプリケーションのデータを誤りなく転送するためには、TCP（Transmission Control　Protocol）が用いられる。TCPでは、送信したデータに対して受信確認の応答を受信・処理することで誤りなくデータを受信するものである。
　非特許文献５にもあるように、そのスループットは、RTT、およびパケット損失率に依存する。ここで、RTTには、送受信間での往復での伝搬遅延と、往復時の装置内におけるパケットのプロトコル処理遅延および回線上への転送遅延等が含まれる。なお、送受信間の往復では往路と復路で同一の経路を通過するとは限らない。
　一般に、送受信間でインターネット上でのホップ数が大きくなるとパケット損失率が増加し、また特に異なる大陸もしくは諸島間をつなぐ海底ケーブルによるAS間のリンクを含む場合は、その伝搬遅延によりRTTが大きくなる。これによりTCPによるデータ転送時のスループットは低下する。
　また、TCPのフロー制御では、受信応答なしに連続して送出できるデータ量の上限を決めるウィンドサイズを、受信応答の戻りかたに応じて動的に変更する。この制御は、Additive increase multiplicative decrease則に基づいている。よってパケットのロスがあると判断された場合、そのときのウィンドサイズを半分にするため、データを転送できる量が半減する。
　従って、非特許文献６にあるように、こうしたＴＣＰの性質を考慮して、アプリケーションレベルでのスループットを増大させるには２つの方法が考えられる。一つは、アプリケーションレベルの中継装置をおいてＲＴＴを減らすことである。ここで、最大ウィンドサイズをW、リンクeでのＲＴＴをTeとすれば、そのリンクにおけるスループットは、W/Teとなるので、あるパスhでのスループットは各リンクでのスループットの中の最小値となり、パスhに含まれるリンクの集合をEhとすれば、min_{e∈Eh} W/Teで計算できる。よって、パスにおける最大のTeが最小になるようにパスを選べばスループットは最大化できる。
　もうひとつの方法は、隣接サイト間でＴＣＰコネクションを並列に設定することであり、コネクション数をZとすれば、スループットはZ*W/Teとなる。また、パケット損失をひとつ検出した場合、１本だけ設定したＴＣＰコネクションにおいて最大ウィンドサイズＷをZ倍にしておいたとすれば、ウィンドサイズはZ*W/2に減少するが、ＴＣＰコネクションをZ個並列に設定しておけば、パケット損失は一つのコネクションにおいてのみ検出されることになるので、最大ウィンドサイズの合計は、W/2+(Z-1)*Wとなって、差し引きは(Z-1)*W/2となる。よって並列設定数Zが大きいほどスループットが高くなることが期待できる。
C. Bornstein, T. Canfiled, G. Miller, S. B. Rao, and R. Sundaram, “Optimal routeselection in a content delivery network,” US patent 7,274,658, Sep. 25, 2007. F. Thomson Leighton and Daniel M. Lewin, “Global hosting system,”USpatent 6,108,703, August 22, 2000. D. Karger, E. Lehman, F.T. Leighton, M. Levine, D. Lewin, and R.Panigrahy, “Method and apparatus for distributing requests among a plurality ofresources,” US patent 7127513, October 24, 2006.
K. Park and V. S. Pai, "Scale and performance in the CoBlitz large-file distributionservice," NSDI’06. G. Kwon and J. W. Byers, "ROMA: Reliable overlay multicast withloosely coupled TCP connections, " IEEE INFOCOM 2004. D. Anderson, H. Balakrishnan, F. Kaashoek, and R. Morris, "Resilientoverlay networks, " in Proc. 18th ACM SOSP, October 2001. B. Li, S. Xie, Y. Qu, G. Keung, C. Lin, J. Liu, and X. Zhang, "Inside the newcoolstreaming: principles, measurements and performance implications," IEEE INFOCOM’08. J. Padhye,V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP throughput: A simple modeland its empirical validation,"ACM SIGCOMM Computer Communication Review, vol.28no.4, pp. 303-314, Oct. 1998. Y. Liu, Y. Gu, H. Zhang, W. Gong, and D. Towsley, "Application levelrelay for high bandwidth data transport," GridNet 2004. http://en.wikipedia.org/wiki/Representational_State_Transfer http://en.wikipedia.org/wiki/Squid_(software) R. Cohen and G. Kaempfer, "A unicast based approach for streamingmulticast", IEEE INFOCOM 2001. Y. Miyao, "An optimal design scheme for global overlay networks withenhanced data transfer throughput, "ICC2010. D. G. Thaler, and C. V. Ravishankar, "Using name-based mappings toincrease hit rates," IEEE/ACM Transactions on Networking vol. 6, No. 1, pp.1-14, February 1998. HTTP1.1, IETF RFC2616, June, 1999.http://www.w3.org/Protocols/rfc2616/rfc2616.html http://en.wikipedia.org/wiki/Ajax_programming
　しかしながら、上述した文献に開示された技術では、以下のような問題がある。まず、上記特許文献１には、まだオリジンサイトとエッジサイトの間のスループットを増大させる余地がのこっている。なぜなら、中継サイトになる候補のサイトからのみRTTを測定するので、片方向しかみておらず、ルートの非対称性が大きいサイト間がある場合は、適切な制御ができないからである。また、エッジサーバからオリジンサーバまで最大２ホップまでしか考慮されておらず、よりホップ数が許さればサイト間のRTTが押さえられてスループットが増大する可能性があるからである。
　また、非特許文献２では、（上記特許文献１における２ホップという制限を越えて）配信経路を最適化するが、動的な最適化の具体的方法が示されていない。また、非特許文献３は、動的にポイントツーポイントのオーバレイパスの設定を行うが、複数のサイトへの分配には対応していない。また、動的再構成のための性能測定と、その統計値の取得は別々の手順で実行する必要がある。
　さらに、上記特許文献１では、動的にエッジサーバとオリジンサーバとのポイントツーポイントの経路設定できても、オリジンサーバから複数のエッジサーバに効率的に分配する経路を設定することができない。なぜならオリジンサイトへの直通パスと中継サイトを含む２つの経路候補の中から一つを選ぶ際に、中継サイトに欲しいデータがキャッシュされているかどうかを判断指標にいれないからである。
　また、非特許文献４は、並列分割転送する分、スループットを増大できるが、サイトに複数のサーバを設置して収容能力を増大させるような状況には対応していない。なぜならいわゆるピアツーピア形式でファウルをクライアント同士で分配することを前提としているからである。
　また、非特許文献１は、まだスループットを増大させる余地がある。なぜなら、分割したブロック毎に中継サーバを割り当てるが、それは２ホップ目におけるものだけだからである。また、非特許文献１では、ブロック数が増えると処理負荷や必要資源が増加するという問題がある。なぜなら、ブロックを転送する毎にHTTPコネクションを設定する必要があり、また、ドメイン解決のためのメッセージ処理数が増えるからである。
　さらに、非特許文献４の問題点としてすでに記述しているが、上記特許文献１以外の技術では、サイト内でのサーバクラスタ化による収容能力の増大を考慮することができない。
　このため、本発明の目的は、上述した課題である、ネットワーク上に分散配置された複数のサーバ装置間におけるデータ転送のスループットを改善する、ことにある。
　上記目的を達成すべく、本発明の一形態であるデータ転送システムは、
　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されており、
　前記ドメイン解決サーバが、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を備え、
　前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
　前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である親サイトにあるプロキシサーバを自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
という構成を採る。
　また、本発明の他の形態であるドメイン解決サーバは、
　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバであって、
　各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を備え、
　前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
　前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
という構成を採る。
　また、本発明の他の形態であるプログラムは、
　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバに組み込まれるプログラムであって、
　前記ドメイン解決サーバに、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を実現すると共に、
　前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
　前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
という構成を採る。
　また、本発明の他の形態であるデータ転送方法は、
　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおけるデータ転送方法であって、
　前記ドメイン解決サーバが、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測し、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定し、前記ドメインに対応するプロキシサーバを割り当てると共に、
　前記経路設定時に、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
　前記割り当て時に、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
という構成を採る。
　本発明は、以上のように構成されるため、これによると、ネットワーク上に分散配置された複数のサーバコンピュータ間におけるデータ転送のスループットの向上を図ることができる。
データ転送システム全体の構成を示すブロック図である。 第１の実施形態におけるサイト内の構成を示すブロック図である。 第１の実施形態におけるドメイン解決サーバの構成を示すブロック図である。 第１の実施形態における親DRS記憶部のテーブル構成を示す図である。 第１の実施形態におけるRTT統計記憶部のテーブル構成を示す図である。 第１の実施形態における親DRS決定部の動作を示すフローチャートである。 第１の実施形態における親DRS決定部の動作を示すフローチャートである。 第１の実施形態におけるPS割当て部の動作を示すフローチャートである。 第１の実施形態におけるPS割当て部の動作を示すフローチャートである。 第１の実施形態の実施例におけるDRS間のRTT計測とRTT統計情報取得の説明図である。 第１の実施形態の実施例における最適分配木の作成と親DRS記憶部のテーブル構成の説明図である。 第１の実施形態の実施例として、ドメイン解決要求・応答メッセージの転送とHTTPリクエスト／レスポンスのデータ転送の一連の動きを示す説明図である。 第１の実施形態の実施例として、オリジンサイトから各サイトにデータを分配する動作の説明図である。 第２の実施形態におけるDRSの構成を示すブロック図である。 第２の実施形態におけるDRSの分配木算出部の動作を示すフローチャートである。 第２の実施形態におけるDRSのPS割当て部の動作を示すフローチャートである。 第２の実施形態における実施例として、ドメイン解決・要求メッセージの転送とHTTPリクエスト・レスポンスのデータ転送に関する一連の動作の説明図である。 第３の実施形態におけるOGSの構成を示すブロック図である。 第３の実施形態におけるOGSの発行処理部の動作を示すフローチャートである。 第３の実施形態におけるOGSのクライアント処理部の動作を示すフローチャートである。 第３の実施形態におけるDRSの親ＰＳキャッシュ部のテーブル構成を示す図である。 第３の実施形態におけるDRSのＰＳ割り当て部の動作を示すフローチャートである。 第３の実施形態におけるDRSのＰＳ割り当て部の動作を示すフローチャートである。 第３の実施形態におけるDRSのＰＳ割り当て部の動作を示すフローチャートである。 第３の実施形態におけるクライアントの構成を示すブロック図である。 第３の実施形態におけるクライアントの背景処理部の動作を示すフローチャートである。 第３の実施形態における実施例として、クライアントとエッジサイトとの間の一連の動作を示す説明図である。 第３の実施形態の実施例において、オリジンサイトからクライアントまでの転送経路上でのサブストリームの並列転送を示す説明図である。 第４の実施形態におけるサイトの構成を示すブロック図である。 第４の実施形態におけるDRSのPS割当て部の動作を示すフローチャートである。 第４の実施形態における実施例として、サブストリーム乗換えを示す説明図である。 本発明の付記１－１におけるデータ転送システムの構成を示すブロック図である。 本発明の付記２－１におけるデータ転送システムの構成を示すブロック図である。
　＜実施形態１＞
　本発明の第１の実施形態を、図１乃至図１１を参照して説明する。図１乃至図５は、データ転送システムの構成を示す図であり、図６乃至図１１は、データ転送システムの動作を示す図である。
　［システム全体構成］
　図１に示すように、本発明におけるデータ転送システムは、クライアント４１～４４と、分配システム２２と、からなる。そして、分配システム２２は、クライアント４１～４４に対して、コンテンツの投稿や配信のサービスを行なうもので、複数のサイト１０１～１０４と、それらをつなぐサブネットワーク１８と、により構成されている。
　上記クライアント４１～４４は、所定のユーザが操作するパーソナルコンピュータなどの情報処理端末であり、適切なサイトに誘導されて、HTTPを用いてコンテンツをアップロードしたり、ダウンロードしたりする機能を有する。また、クライアント４１～４４は、サブネットワーク１８とは同じもしくは独立のネットワークを通じて、サイト１０１～１０４とコンテンツをやり取りする。
　図２に示すように、サイト１０２は、オリジンサーバ（OGS）２０２と、ドメイン解決サーバ３０２（DRS）、プロキシサーバ（PS）５０３～５０５と、マルチレイヤスイッチ（MLS）１９と、エッジルータ２０と、を備えている。
　オリジンサーバ（OGS）２０２は、コンテンツのアップロードを受け付ける。ドメイン解決サーバ（DRS）３０２は、他のサイトのDRSからの要求に基づいて、コンテンツデータ要求（HTTPリクエスト）を転送する先のプロキシサーバ（PS）のアドレスの解決を行う。エッジルータ２０は、サイト内の各装置とサブネットワークとの接続をIPレベルで行うものである。MLS１９は、OGS２０２、PS５０３～５０５、DRS３０２、エッジルータ２０を接続する。
　なお、全てのサイト１０１～１０４はほぼ同一の構成を採っているため、ここでは、符号１０２に示すサイトのみを説明する。以下、各構成について詳述する。
　［オリジンサーバ（OGS）］
　まず、オリジンサーバ２０２（OGS）は、ドメイン毎に転送先のＰＳのドメイン解決を要求する既存のクライアントやプロキシサーバＰＳを前提に、異なるＵＲＩ毎に次ホップのサイト内に複数あるPSの一つを割当てるため、特許文献２にあるようなURIの変換を行う。なお、ＵＲＩ単位でドメイン解決要求をすることができる場合は、このＵＲＩの変換は不要になる。すなわちOGS２０２では、コンテンツ発行者から新たにアップロードされたコンテンツのデータを、ＨＤＤ等の記憶装置に格納した後、そのファイルに以下のようなO-URIを付与する。
　O-URI-- http://www.site1.song.net/videocast/channel3/item2/
　ここでO-URIの構成の仕方について説明しておく。「song.net」は、この配信サービスを提供する主体を示し、「site1」は、このコンテンツが発行者からアップロードされた先であるオリジンサイトを示し、「www」は、オリジンサーバとしてのホスト名を示している。配信サービス提供主体がN個のサイトを運営している場合、例えば各サイトをsite1,…, siteNと示す。」
　次にO-URIのパスの部分において、「videocast」はコンテンツ提供サービスの名称を、「channel3」は、個別のチャンネルを、「item2」は、個別の配信プログラムをそれぞれ示している。
　次に、O-URIをハッシュして（この値をここでは1578とする）、それにfをつけて得られるf1578というドメインをwwwと入れ替えて、次のようにF-URIを得る。
　F-URI: http://f1578.site1.song.net/videocast/channel3/item2/
　ここで説明を簡単にするため、以下のようにドメインの呼び方をつける。
「Oドメイン」：site1.song.net　オリジンサイトに対応するサブドメイン。詳細は後述するが、オリジンサイトを示すドメインを含ませることで、オリジンサイト毎にそれをルートにもつ有向分配木を作成してドメイン解決要求をその分配木上の経路にそって転送することができるようになる。
「Fドメイン」：f1578.site1.song.net　異なるO-URIに対応するように変換されたのちのドメイン名。
　O-URIは、ポータルサイトでデータを取得するためのリンクとして使われ、それをクリックすると、O-URIを含むHTTPリクエストがオリジンサイトに送られ、そこから番組ファイルを取得するために使われるメタデータがHTTPレスポンスとしてクライアントにダウンロードされる。下記はそのメタデータに含まれる情報である。
　O-URI: http://www.site1.song.net/videocast/channel3/item2/
　エッジサイトDRSのアドレス：291.47.234.12, 291.47.234.13
　F-URI: http://f1578.site1.song.net/videocast/channel3/item2/
　ここで、エッジサイトに設置されたDRSのアドレスは、クライアントがメタデータの要求をしてきたタイミングで、そのクライアントのＩＰアドレスに基づいて、クライアントを誘導すべき最寄りのエッジサイトのDRSのアドレスとしてオリジンサーバが決定する。ここではDRSの障害を考慮して、２つのDRSアドレスが２つ記載されている。
　上記のメタデータはＸＭＬ形式で記述してもよい。こうして、URIが指定されたリソースの状態をXML形式で提供するＷｅｂサービスは、RESTfulと呼ばれる（非特許文献７参照）。
　なお、特許文献１でも、上記の同じように、異なるURIのコンテンツ毎にキャッシュサーバを割当てるため、オリジナルのURIに対してハッシングを行って仮想サーバを割当て、オリジナルのURIをパスの部分にもっていって、その前にAkamaiの仮想サーバのドメインをつけることで、新たなURIを作る。一方、本発明では、上記とは異なり、配信用のサイトのみならずオリジンサイトもサービス運用者が同時に運用するので、オリジナルのURI全体を変換後のURIのパス部分に埋め込む必要はない。
　［プロキシサーバ（PS）］
　本発明で用いるプロキシサーバ５０３～５０５（以下PSと略す）では、非特許文献８にあるような既存のものへの機能追加機能は最低限にしている。以下にPSの構成及び動作について説明する。
　プロキシサーバ５０３～５０５は、親となるサイトのＰＳからもらったブロックを、キャッシュもしくは記憶しておき、次に別のサイトから要求があったときに備える。ここで分配木の転送経路上で隣接するサイトにおいて、ルートにより近い側のサイト、つまり、上流側のサイトを親サイト、ルートからより遠い側のサイト、つまり下流側のサイトを子サイトと、それぞれ呼ぶ。
　ＰＳは、HTTPリクエストを受信すると、そこに含まれるURIのデータを格納している場合は、それをHTTPレスポンスとして返す。格納していない場合は、DRSにFドメインに対して割当てられるPSのアドレスを得るために、ドメイン解決要求をし、戻ってきたら、そのPSのアドレスに向けて、HTTPリクエストを転送する。HTTPリクエストに対して、HTTPレスポンスが戻ってきたら、そのURIに対して要求していたサーバにHTTPレスポンスを返送する。
　ＰＳでのデータ転送と蓄積は、ＨＴＴＰコンテンツのデータは入出力が速いメモリ上で扱うことを前提とする。これは特にオリジンサイトにおいては、ＯＧＳにおいてメモリよりも読み出しが遅いＨＤＤにあるデータを、ＰＳにキャッシュさせてから転送に使うことで、性能向上を図っている。
　［ドメイン解決サーバ（DRS）］
　図３に示すように、ドメイン解決サーバ（DRS）３０２は、送信装置１４と、受信装置１５と、データ処理装置８と、記憶装置９と、を備えている。送信装置１４および受信装置１５は、他のサイトのDRSとドメイン解決要求・応答メッセージおよびRTT統計値要求・応答メッセージをそれぞれやりとりしている。
　データ処理装置８は、プログラムが組み込まれることで構築された、PS割当て部８１と、親DRS決定部８２と、を備えている。ここで、「親DRS」とは、ドメイン解決要求を次に転送すべき親サイトのDRSを指す。また、「親サイト」とは、後述するように生成された有向分配木の転送経路上で隣接する２サイトの中で、ルートにより近い側のサイト、つまり、上流側のサイトを指す。
　親DRS決定部８２（計測手段、経路設定手段）は、ドメイン解決要求を送るべき親サイトのDRSのアドレスを決定する。PS割り当て部８１（割り当て手段）は、子サイトのDRSからの要求に基づいて、各サブストリームに対して自サイトで割り当てるべきPSのアドレスを決定する。
　受信装置１５は、ドメイン解決応答はPS割り当て部８１に、RTT統計値応答は親DRS決定部８２にそれぞれ渡す。また、記憶装置９は、ローカルPS記憶部９１と、親PSキャッシュ部９２と、親DRS記憶部９３と、RTT統計行列記憶部９４と、RTT統計処理記憶部９５と、分配木記憶部９６と、からなる。
　上記ローカルPS記憶部９１は、自サイトにあるPSのアドレスと、タイムアウト回数と、状態の組合せからなるエントリを格納している。親PSキャッシュ部９２は、親DRSから解決応答として受取ったＦドメインと親PSアドレスとの組合せを含むエントリをテーブルとして持つ。
　親DRS記憶部９３は、親DRS決定部８２が算出した、オリジンサイトをルートとする有向分配木において、自分に対する親サイトのDRSのアドレスとその状態を記憶する。また、この親DRS記憶部９３内のTTLは、この情報が有効である残り時間を示し、この値は時間経過とともに小さくなる。このテーブルの特徴は、HTTPリクエストの転送先ではなく、ドメイン解決のための転送先が書いてあることである。また、通常のシステムでは、URIによらず共通の親PSを割当てていたが、本発明で割当てる親DRSは、オリジンサイト毎に異なる。
　ローカルＰＳ記憶部９３は、ローカルサイト内に設置されている各ＰＳのアドレスと、その状態が格納されている。
　RTT行列記憶部９４は、サイトiからサイトjへのRTTを所定の回数の測定した結果から得られる統計値が行列状に格納されている。ここで、他のサイトから自サイトへのＲＴＴ統計値は、ＲＴＴ統計値応答に対して受信したＲＴＴ統計値応答内に記載された値を、また自サイトから他サイトへ測定した値は自サイトのRTT統計記憶部９５内のテーブルにあるＲＴＴの最小値（図５参照）を、それぞれRTT行列記憶部９４の対応するエントリにコピーしたものである。
　ここで、図４は、親DRS記憶部９３のテーブル構成を示す図である。このテーブルは、Oドメインと、オリジンサイトのDRSのアドレスと、親サイトのDRSのアドレスと、親サイトのDRSの状態と、からなる。
　また、図５は、DRSi (i=1,…,N)におけるRTT統計記憶部９４のテーブル構成を示す図である。自分以外の他の全てのサイトに関するＮ－１個のエントリをもつ。DRSjに対するエントリは、DRSj(j=1,..,i-1,i+1,...,N)のアドレスと、過去Ｍ回分のＲＴＴの測定値TjM,...,Tj1と、それらの最小値 min(Tj1,...,TjM)と、DRSの状態の組合せとなっている。新たな測定値を得たら、Ｍ個あるRTTの過去の測定値を左側にシフトさせて、TjMは削除し、一番右の空いたTi1のところに最新の測定値を書くとともに、過去Ｍ回分のRTTの最小値を更新する。この処理自体は、親DRS決定部８２が行う。
　［親DRS決定部の動作］
　次に、上述したシステムの動作を説明する。はじめに、図６ａ、図６ｂを参照して、親DRS決定部８２の動作について説明する。
　図６ａは、他サイトのDRSへのＲＴＴ統計値要求の送信に対するＲＴＴ統計値応答の受信により、自サイトからその他サイトへのＲＴＴの測定を同時に行いつつ、ＲＴＴ統計値が変動した場合は分配木を再構成する動作を示している。なお、非特許文献１にもあるように、分配木は各サイト間のスループットを全て最大化させるためのものである。
　まず、ステップＳ６１で、各サイト１０１等の親DRS決定部８２は、RTT統計値要求を定期的に他の全てのサイト１０２等のDRS３０２等へ送信する。この間隔は、予め設定された任意の間隔であるが、例えば、１５－３０分である。このときタイムアウト回数Ｎは０にしておく。
　ここで、ＲＴＴ統計値要求は、下記のＵＲＩをもつＨＴＴＰリクエストとする。
　　http://(要求先のDRSのアドレス)/RTTstatistics
　続いて、ステップＳ６２で、ＲＴＴ統計値要求を送った他のサイト１０２等のDRSjから、
　ＲＴＴ統計値のベクトル
　{(DRS1,T1),..,(DRSj-1,Tj-1,),(DRSj+1,Tj+1),…,(DRSN,TN)}
　（ただし、TkはDRSｊからDRSｋに対して測ったＲＴＴの統計値）
を含むRTT統計値応答がタイムアウトせずに戻ってきたら、RTTの測定値（要求を送ってから応答が届くまでの時間）をRTT統計記憶部９５に書き込んで、統計値を更新し、その更新値でさらにRTT行列記憶部９４を更新する。なお、ＲＴＴ統計値応答は、上記RTT統計値のベクトルをＸＭＬで記述したものを用いてもよい。
　タイムアウトした場合は、Nをインクリメントし、もう一度要求を送る。これを繰り返して、Ｎが所定値（例えば３）を超えた場合は、使用不可という状態をRTT統計記憶部９５の状態のところに書き込む。また、RTT行列記憶部９４では、使用不可を書き込む。そして、ＲＴＴ統計値応答メッセージ内にある、応答のあったサイトから他の全てのサイトに対して得られたＲＴＴ統計値を、RTT行列記憶部９４に書き込む。この動作はＲＴＴ統計値要求を出した他のすべてのサイトに関して行う。
　次に、ステップ６３で、RTT行列記憶部９４を参照して、各サイトがオリジンサイトとなる最適分配木を算出する。そして、分配木記憶部９６を参照して分配木に変更があるＯドメインがある場合は、そのＯドメインに対する親サイトのDRSを抽出して、親DRS記憶部９３を更新し、親PSキャッシュ部９２において、変更のあった分配木に対応する部分（O-ドメインで識別）をクリアし、更にローカルPSのアドレスキャッシュにおいて、該当Oドメインを含む全てのB-URIのエントリを管理手順で強制的にクリアして、ステップ６１に飛ぶ。
　これらのクリアを行うのは、分配木の再構成があった場合に、上記各テーブルの更新をＴＴＬに頼るのではなく、直ちに再構成が反映されるようにするためである。
　なお、上述したように親DRS（親ドメイン解決サーバ）を特定する方法は、例えば、構成された有向分配木の転送経路上で隣接するサイトにおいて、ルートにより近い側のサイト、つまり、上流側のサイトのDRSを、親DRSとして特定する。
　ステップ６３においては、各サイトのDRSは、予め他の全てのサイトのDRSのアドレスを知っているものとする。これは、例えばシステム全体をつかさどる管理システムが、サイトの追加もしくは離脱の度に稼動する全てのサイトにDRSのアドレスを通知することで実現する。
　また、ステップ６３において最適な有向分配木を算出する一つの方法として、非特許文献９にあるようなボトルネック（帯域が最小のリンク）を最大化する方法がある。この方法の目的は各サイト間の転送スループットを最大化することである。
　ここで、隣接サイト間のＲＴＴと最大ウィンドサイズＷが与えられれば、パケットロスがないとした場合の隣接サイト間のリンクeでのスループットはW/Teで与えられるので、あるサイト間のパスhでのスループットは、hに含まれるリンクeの集合Ehとすると、そのパス上のボトルネックであるmin_{e∈Eh}W/Te で与えられる。よって各リンクでＷは一定であるとすれば、Teをコストとして、最小全域木を作る手順の一つであるプリム法を応用すれば、各サイト間のスループットを最大化できる。証明は、非特許文献１０に記述されている方法を参考にすれば導かれるがここでは省略する。この手順では部分木に対してノードを追加していくのに、部分木に付加することが可能なリンクのなかでRTT統計行列記憶部の中に格納されているRTT統計値が最小のリンクの先にあるノードを追加していく。
　なお、ここで仮想リンクとは、サイトＡからサイトＢへのリンクが物理的なものではなく、インターネットもしくは専用網の転送機能によって実現されているようなものをさす。ここでの分配木を作る手順は、ノード数Ｎ、有向リンク数Ｎ（Ｎ－１）のフルメッシュな有向グラフから、最適な有向分配木を抽出することであるともいえる。
　また、ステップ６３において、最適な有向分配木を算出するもう一つの方法として、ダイクストラのアルゴリズムがある。ただし、サイトiからサイトjへのエッジのコストにはＲＴＴ統計値を付与する。なぜなら各エッジサイトからオリジンサイトでのリンク上でのＲＴＴの総和を最小にする最短パスツリーを算出したいからである。これは、サイト内でのドメイン解決の時間を無視すれば、クライアントがエッジサイトに取得したいファイルに関して最初にＨＴＴＰリクエストを出してから、エッジサイトが初めてＨＴＴＰレスポンスを受信するまでの時間を概算するものである。このいわゆるスタートアップ時間は、各エッジサイトからオリジンサイトまでの方向のパス上の各サイト間の仮想リンクでのＲＴＴ統計値の総和の２倍で与えられる。例えば、後述する図１０においては、Ｓ５，Ｓ６，Ｓ８、Ｓ１０，Ｓ１１，Ｓ１３，Ｓ１５，Ｓ１６，Ｓ１８，Ｓ２３，Ｓ２４，Ｓ２５で関る仮想リンクのRTT統計値の総和を取ったものに相当する。
　また、図６ｂは、他のサイトのDRSからRTT統計値要求を受けた場合の処理である。ステップＳ６５でRTT統計値要求を他サイトのDRSより受信したら、ステップＳ６６でRTT統計記憶部９５に記憶されている各リモートDRSに関するRTT統計値を、RTT統計値応答に載せて要求してきたDRSに送信して終了する。
　［PS割当て部の動作］
　次に、図７ａ、図７ｂを参照して、DRS３０２のPS割当て部８１の動作について説明する。図７ａは、PS割り当て部８１におけるドメイン解決の動作を示すものである。ドメイン解決に関するメッセージは、１）クライアントもしくは子サイトのDRS、２）ローカルＰＳ、および、３）親サイトのDRS、とやり取りするが、それぞれに対して手順が以下のようになる。
　まず、ステップＳ７１で、クライアントもしくは自サイトプロキシからFドメインに対する親PSのドメイン解決要求があると、ステップＳ７２で、（１）Ｆドメインに自分と同じＯドメインを含む場合は、ドメイン解決応答でＯＧＳのアドレスを返す。（２）Ｆドメインに自分と同じＯドメインを含まない場合であり、対応エントリが親ＰＳキャッシュ部９２にある場合は、そのドメイン解決応答する。（３）対応エントリが無い場合は、親DRS記憶部９３を参照して当該Oドメインに対応する親DRSに対してFドメインの親PSアドレスの解決を要求する。
　また、ステップＳ７３で、親サイトのDRSからドメイン解決応答があったら、ステップＳ７４で、Fドメインに対して割当てられたPSのアドレスを親PSキャッシュ部９２にキャッシュし、解決要求していたローカルPSに対して割当てられたアドレスで応答する。
　また、ステップＳ７５で、子サイトのDRSからFドメインに対するドメイン解決要求があったら、ステップＳ７６で、ローカルPS記憶部９１を参照してロバストハッシングによりFドメインに対応するPSアドレスを決定し、解決要求してきた子DRSにそのアドレスを応答して終了する。
　図７ｂは、PS割当て部８１におけるローカルPSの監視動作を示すものである。ステップＳ７７で、前回の監視動作から一定時間経過後、タイムアウト回数Ｎを０にして、ローカルPS記憶部９１にある各PSアドレスに向けてpingを送信する。ステップＳ７８で、（１）タイムアウトせずに戻ってきた場合は、そのPSの状態を使用化とする。（２）タイムアウトした場合は、Nをインクリメントしてpingを再び送信する。そのタイムアウト回数が一定数以上になった場合は、そのPSの状態を使用不可とする。そしてステップB７に戻る。
　［ステップＳ７６におけるPS割当てアルゴリズム］
　図７ａのステップＳ７６におけるロバストハッシングとしては、非特許文献１１、もしくは、特許文献３にある方法に基づいて行う。これは、同じコンテンツが複数のPSに複製されることをなるべく防ぐ一方で、PSが増設もしくは減設されたときに、既存のPSを割当てられているFドメインに別のPSが割当てられるような割合を最小にするためのものである。もし、あるサーバが使用不可になった場合は、そこに転送していた子PSがあらたに子DRSに解決要求をして、それがさらに親DRSに要求をしてくるので、そこに新たに割当てることになる。
　次に、上述した本発明の第１の実施形態における効果について説明する。本実施形態によると、各サイトをノードにもつ分配木はアプリケーションレベルでのホップ数を制限なしに最適に構成されるので、ホップ数に制限がある場合に比べて、アプリケーションレベルでのスループットをより向上させることができる。つまり、オリジンサイトが異なる毎に最適な分配木を構成するので、オリジンサイトに関らず固定的な分配木を用いる場合比べて、どのサイトからコンテンツを取得しようとしてもよりスループットを向上させることができる。
　また、分配木は、各サイト間で測ったRTTベースに、オリジンサイトをルートとしてもつ有向グラフとして作成されるので、サイト間の転送状態における非対称性が大きくても（例えば、サイトＡからＢへのＲＴＴとサイトＢからＡへのＲＴＴの差が大きいこと）、スループットをより最適化することができる。
　そして、自サイトから他サイトへのＲＴＴ測定と、他サイトからのＲＴＴ統計情報の取得を同時に行うので、非特許文献３にあるようにそれらを別々の手順で行う必要がなくなり、処理量が削減できる。
　［実施例］
　次に第１の実施形態におけるさらに具体的な実施例を、図８及び図９を参照して説明する。図８、図９は、親DRS決定部８２の動作を示している。
　図８では、DRS１におけるＲＴＴ統計情報の取得、ＲＴＴ測定とＲＴＴ行列の作成の例を示している。ここでは、DRS１が、DRS２,DRS３,DRS４にそれぞれRTT統計情報要求を送った後、ＲＴＴ統計情報応答が戻ってくると同時にRTTを測定する。そして、RTT行列記憶部９４において、各DRSから応答のあったＲＴＴ統計情報は、各DRSが要求側であるエントリに書き込まれる。また、ＲＴＴの測定値は、RTT統計記憶部９５に書き込まれ、その結果新たに得られるＲＴＴ統計値は、自分（DRS１）が要求側のエントリに書き込まれる。つまり、ＲＴＴ統計情報要求を送信してから応答があるまでの時間として計測されたRTTの値は、RSS統計記憶部９５に格納され、統計値として処理された結果がRTT行列記憶部９４に書き込まれる。
　図９は、RTT行列記憶部９４の内容に基づいて、親DRS記憶部９３のテーブルを作成する動作例を示している。ここでは、まず、各DRSがオリジンサイトになる有向分配木が４つ作成される。そして、各DRSにおける、オリジンサイト毎の親DRSの対応表は図９に示すようになり、これが親DRSアドレス記憶部９３に組み込まれることになる。つまり、構成された有向分配木の転送経路上で隣接するサイトにおいて、ルートにより近い側のサイト、つまり、上流側のサイトのDRSが、親DRS（親ドメイン解決サーバ）として特定される。
　次に、図１０は、ＰＳ割当て部８１の動作により、クライアントが要求したデータをオリジンサイトまで取りに行くための連係動作の実施例を示している。
　まず、クライアントは、取得したいデータのF-URIと、データを取得するＰＳの解決に使用すべき親サイト１０２のDRS３０２のアドレスとを、OGS２０４から取得したメタデータ内に持っており、HTTPリクエストを送信すべきPSのアドレスを得るために、F-URIに含まれるFドメインに対するドメイン解決要求をDRS３０２に送信する。（Ｓ１）。これは、下記のURIを含むHTTPリクエストを用いてもよい。
　http://(DSR302のアドレス)/PSes/ f1578.site1.song.tv
　続いて、DRS３０２は、それに対してサイト内で割当てるPSをPS５０２と決定したら、そのアドレスp.q.r1.s1を持ってクライアントに応答する（Ｓ２）。この応答は、下記の情報をXML形式で記述したものを本文に含むHTTPレスポンスでもよい。
　f1578.site1.song.tv　　p.q.r1.s1
　次に、クラアント４５は、PS５０２に対してHTTPリクエストを送信する（Ｓ３）。PS502は、HTTPリクエストを受取ったら、そのURIが示すデータをキャッシュしていないので、ローカルのDRS３０２に、Fドメインを、HTTPリクエストを転送すべき親PSのアドレスに解決する要求をだす（Ｓ４）。これはDNSプロトコルで行ってもよい。
　すると、DRS３０２は、該当するFドメインに対して親PSアドレスのキャッシュを持っていないので、親DRS記憶部９３を参照して、Oドメインに対応する親DRSであるDRS301にFドメインの解決要求を出す（Ｓ５）。これは下記のURIを含むHTTPリクエストを用いてもよい。
　http://(DSR302のアドレス)/PSes/f1578.site1.song.tv
　するとDRS301は、PS505を割当てて、そのアドレスp.q.r2.s2でDRS302に解決応答する（Ｓ６）。この応答は下記の情報をXML形式で記述したものを本文に含むHTTPレスポンスでもよい。
　f1578.site1.song.tv　　p.q.r2.s2
　このように指定したＵＲＩに対して、そのリソースの状態をＸＭＬファイルで応答するＷｅｂサービスはRESTfulと呼ばれる（非特許文献７）。
　その応答を受取ったDRS302は、Ｓ４で解決要求をしていたPS502に解決応答する（Ｓ７）。Ｓ４での解決要求がDNSプロトコルで行われた場合は、Ｓ７の解決応答もDNSプロトコルで行われる。
　同様の手順をオリジンサイト１０４まで繰り返すと、HTTPリクエストはORG204まで転送される（Ｓ２１）。これに対してORG204は、F-URIで指定されたデータをHTTPレスポンスで同一サイト内のPS512に返送する（Ｓ２２）。これはさらに、PS507、PS505、PS502と転送され（Ｓ２３，Ｓ２４，Ｓ２５）、最後にクライアント４５に届く（Ｓ２６）。
　図１１は、特にアクセス頻度の高いデータをオリジンサイトから予め各サイトに配置しておくための一連の動作の実施例を示している。
　まず、オリジンサイト104のDRSは、その分配木上のリーフサイトであるサイト１０２のDRSに、配置したいコンテンツのURIにPSを割当てるようドメイン解決要求を出す（Ｔ１）。ここで「リーフサイト」とは、有向分配木において、さらに転送先のサイトがない一番先端のサイトを指す。
　そして、サイト１０２のDRSから解決応答が戻ってくると（Ｔ２）、割当てられたPSに対して、そのコンテンツに対するURIに対してHTTPリクエストを出すように駆動する（Ｔ３）。これにより、サイト102内のPSは、HTTPリクエストを次に転送すべきサイト１０１内のPSに転送する（Ｔ４）。
　より詳細な手順は、図１０と同じなので省略する。同様にして、HTTPリクエストは、Ｔ５，Ｔ６のように分配木上のサイト１０２からオリジンサイト１０４まで転送される。そして、これに基づいてオリジンサイト１０４から配置したいデータが、サイト１０３，１０１を経由してサイト１０２に届く（Ｔ７，Ｔ８，Ｔ９）。サイト103、101内のPSはデータを中継すると同時に本来のPSの機能としてこのデータをそれぞれ格納する。
　これにより、リーフサイトから要求を上げていくだけで、ノンリーフサイトにはオリジンサイトからデータが転送されるときにキャッシュされる。よって、オリジンサイトから他の全てのサイトにHTTPリクエストを出すように指令する必要がない。また、エッジサイトからHTTPリクエスト／レスポンスでデータを取ってくるのと同じ仕組みでデータ配置ができ、PSやDRSに新たにオリジンサイトから各サイトへのプッシュ型配信のための手段を組込むための付加的なコストがかからなくてすむ。
　また、上記システムによると、転送すべきコンテンツのデータのみならず、転送のためのオーバレイネットワークの制御に用いるデータもＨＴＴＰリクエストとＸＭＬファイルを含むＨＴＴＰレスポンスを用いて転送することで、使用するプロトコルがＨＴＴＰに統一できるので、コンテンツ分配・配信のためのオーバレイネットワークの運用が簡素化される。また制御に用いるＨＴＴＰレスポンスはＸＭＬ形式で記述することができるので、機能拡張が柔軟にできるようになる。
　＜実施形態２＞
　次に、本発明の第２の実施の形態について、図１２乃至図１５を参照して説明する。ここでは、上述した第１の実施形態とは異なり、各DRSにおける親DRSの解決は、全てオリジンサイトのDRSが行う、という構成を採っている。
　図１２は、DRSの構成を示すブロック図である。この図に示すように、本実施形態におけるDRSは、データ処理装置８のみが図５と異なり、PS割当て部８１と、分配木算出部８２と、を備えている。
　そして、分配木記憶部９６には、分配木算出部８３を用いて決定した、自サイトがルートとなる分配木に基づいて、自サイトを除いた各サイトとその親サイトとの組合せのエントリが記憶される。
　次に、第２の実施形態の動作について説明する。図１３は、分配木算出部８３で自分がルートの分配木を作成するための動作を示す流れ図である。
　ステップＳ６１、Ｓ６２は、実施形態１で説明した図６ａと同じである。ステップＳ６３’は、図６ａのステップＳ６３とは異なり、自サイトがオリジンサイトとなる有向分配木のみを算出する。そして、分配木記憶部９６を参照して、あらたに算出された分配木の構成が変わった場合は、分配木記憶部９６を更新し、そこから親DRSに変更のあった他のサイトを割り出して、変更がある全てのサイトのDRSに新しい親DRSを通知してステップＳ６１に戻る。この通知は、HTTP PUT リクエストを用いて行ってもよい。
　なお、分配木算出部８３が他のサイトからのＲＴＴ統計値要求に対して行う動作は、図６ｂと同じなので、その説明は省略する。
　図１４は、PS割当て部８１の自サイト内のドメイン解決に関する動作を示すフローチャートである。ここでは、図７ａに追加する機能についてのみ説明する。
　ステップＳ７９で、あるオリジンサイトのDRSから親DRSの変更があったら、ステップＳ８０で、親DRS記憶部９３を更新し、親PSキャッシュ部９２で、オリジンサイトのDRSに対応するOドメイン（親DRS記憶部を参照すればわかる）を含む全Fドメインのエントリをクリアし、ローカルPSのアドレスキャッシュにおいて、当該Oドメインを含む全てのB-URIのエントリを管理手順で強制クリアする。
　これらのクリアを行うのは、分配木の再構成があった場合に、上記各テーブルの更新をＴＴＬに頼るのではなく、直ちに再構成が反映されるようにするためである。上記に加えて、図７ｂと同じローカルＰＳの監視動作を行う。
　以上説明した第２の実施形態の構成によると、各DRSは、自らがルートとなる分配木のみを算出して、その再構成後に更新のあった親DRSを他の全てのDRSに通知する。よって、各サイトのDRSが独立に親DRSテーブルを作成する分散型の第１の実施形態に比べて、次の効果がある。ひとつは、各DRSが持つ親DRSテーブルの内容が一致しないことでHTTP転送パスの最適性が失われる時間を削減することができる。最適性が失われたことの端的な例としては、分配木の再構成の前後でパスが変化したために、HTTPリクエストが再び同じPSに戻ってくることも起こりうる。これはPSが自分のアドレスをX-Forwarded-Forヘッダ内に記載されていることを見つければ、検出することができる。
　また、上述した第１の実施形態では、各サイトのDRSが各DRSのサイトがルートとなる分配木をすべて算出する必要があるのに対して、この第２の実施形態では、自分がルートとなる分配木だけ算出すればよいので、計算量が削減できる。
　次に、図１５を参照して、第２の実施形態に関する実施例を説明する。ここでは、実施形態１で説明した図１０の場合とは異なり、オリジンサイトのDRS３０４は、分配木が変更されたら親DRSの変わった各DRSに対して、Ｏドメインと親DRSの組合せを通知する。ここでは、Ｕ１，Ｕ２，Ｕ３で、DRS３０２，DRS３０１，DRS３０３に、親DRSを通知している。なお、他の動作は図１０と同じであるため、その詳細な説明は省略する。
　＜実施形態３＞
　次に、本発明の第３の実施形態を説明する。ここでは、第１、２の実施形態で設定された最適分配木による経路上において、スループットをより向上させるために、予めORGでファイルを分割してできたブロックのデータを、サイト間で並列に転送する点に特徴を有する。ただし、ブロック毎ではなく、並列転送されるサブストリーム単位でドメイン解決をすることで、制御負荷を削減する。
　［オリジンサーバ（OGS）］
　図１６に示すように、本実施形態におけるオリジンサーバOGS２は、送信装置１２、受信装置１３、処理装置１０、記憶装置７からなる。
　処理装置１０（コンテンツ配信手段）は、プログラムが組み込まれることで構築された、発行処理部１００１と、Webサーバ処理部１００２と、クライアント処理部１００３と、を備える。
　Webサーバ処理部１００２は、クライアントから受信したHTTPリクエストに対して、コンテンツのデータを送信したり、格納してあるデータをＨＴＭＬデータに作り上げてそれをＨＴＴＰで送り出したりする機能を有する。特に、本実施形態では、後述するように、経路上の同一のサイトに設置された複数のPSに対して、コンテンツを分割したブロック群からなるサブストリームデータを、クライアントに対して並列配信する。
　発行処理部１００１は、取得したデータに対してURIを付与・変換する等の加工アプリケーションにより実現される。
　クライアント処理部１００３は、Ｗｅｂサーバ処理部１００２からクライアントからのメタデータ要求を受取ったら、対応するメタデータを取り出し、クライアントのＩＰアドレスに基づいて地理データ記憶部７３を参照して、最寄りのエッジサイトのDRSを決定し、メタデータに書き加えて、Ｗｅｂサーバ処理部１００２に渡す。
　記憶装置７は、ブロック記憶部７１と、メタデータ記憶部７２と、地理データ記憶部７３と、からなる。ブロック記憶部７１は、アップロードされたコンテンツのデータを記憶する。メタデータ記憶部７２には、Ｏ－ＵＲＩやパラメトリック表現したB-URIや発行者が付与したメタデータが記憶される。地理データ記憶部７３には、各サイトのDRSのアドレスと、それが対応するＩＰアドレスの範囲が格納されている。なお、記憶装置７は、例えば比較的容量の大きいストレージサーバ等で実現される。
　次に、図１７ａを用いてORGの発行処理部７１における動作について詳しく説明する。まず、ステップＳ１７１で、Webサーバ処理部１００２からアップリードされたデータを渡されたら、ステップＳ１７２でファイルを１つもしくは複数のブロックに分割して、それぞれにURIをつけ、ブロック記憶部７１に格納する。その後、ステップＳ１７３で、メタデータを生成して、発行者からのメタデータと統合して、新たなメタデータを作り、URIを付与して対応したメタデータ記憶部７２に格納する。
　次に、ステップＳ１２７でブロック毎につけるURIについて説明する。まず、各ブロックは必ずしも同じサイズである必要はない。そして、各ブロックを並列転送する際、同一PS間のHTTPコネクション上を転送されるブロックの集合をサブストリームデータと呼ぶことにする。すなわち、並列転送とは、それぞれがコンテンツを分割した複数のブロック（分割データ）を含む各サブストリームを複数、同時に転送していることといえる。
　ただし、クライアントで受信後に直ちにビデオ再生できるようにするために、各ブロックは、巡回的に異なるサブストリームに属するようにする。すなわち、サブストリームの総数をZとすると、ブロックIDに対するサブストリームIDは、次で与える。
　(サブストリームID)= {(ブロックID)-1} mod Z+1
　つまり、各ブロックに、コンテンツが再生される順番に対応した識別番号であるブロックIDが付与されている場合には、ブロックID（実際には、ブロックID-1）をサブストリームの総数Zで割り、その余りの値（実際には、余りの値+1）を、当該ブロックが配置されるサブストリームのIDとする。このとき、各サブストリームには、ブロックIDが小さい順に先頭から配置することで、コンテンツ上における再生順序が早い順に、各ブロックが各サブストリームの先頭側から分散して配置される。これにより、各サブストリームが並列転送されても、コンテンツの先頭から配信することができる。
　そして、サブストリーム単位でPSを割当てるようなドメイン解決をPSが行うことができるように、次に示すようなURIの変換を行う。なお、サブストリームの総数は、予めＺ＝３と与えられているものとする。また、ORG（ここではsite1で識別される）において、アップロード直後番組ファイル毎に付与されるURI（これをO-URIと呼ぶことにする）は、次のような構造をもつものとする。
　O-URI： http://www.site1.song.net/videocast/channel3/item2/
　ここで、「song.net」はこの配信サービスを提供する主体を示し、「site1」はこのコンテンツが発行者からアップロードされた先であるオリジンサイトを示し、「www」はオリジンサーバとしてのホスト名を示している。配信サービス提供主体がN個のサイトを運営している場合、例えば各サイトをsite1,…, siteNと示す。また、パスの部分において、「videocast」はコンテンツ提供サービスの名称を、「channel3」は個別のチャンネルを、「item2」は個別の配信プログラムをそれぞれ示している。
　このファイルをセグメント化して得られるブロックに付与するURIは、O-URIの再後尾にブロック番号を示すものを加えて、B-URIと呼ぶことにする。
　B-URI： http://www.site1.song.net/videocast/channel3/item2/block6
　なお、背景技術のところでも記述したように、非特許文献１でも、B-URI相当のものを含むHTTPリクエストを中継経路上のPSに転送するが、B-URIを付与するのは本発明ではOGSであるのに対して、上記非特許文献ではO-URI相当を含むHTTPリクエストをクライアントから最初に転送されたプロキシが行う。
　次にB-URIは、ＰＳが同一アイテム内のブロックから複数構成されるサブストリーム単位でプロキシサーバを割り当てることができるように、以下のように変換される。すなわち、
（１）まずO-URIをハッシュして（この値をここでは1578とする）、それにfをつけたf1578をもうけ、次にサブストリーム数３にzをつけたz3と一緒にしてz3f1578というドメインを作る。
（２）次にブロックIDの6に対するサブストリームIDの２とサブストリーム総数３に対して、s2というドメイン作る。
（３）最後に、上記を結合したs2.z3f1578というドメインを、最初のB-URIのwwwと入れ替える。
　すると変換後のB-URIは次のようになる。
　http://s2.z3f1578.site1.song.net/videocast/channel3/item2/block6
　ここで、z3f1578.site1.song.netのように同一ファイルに対応するドメインをＦドメインと呼び、s2.z3f1578.site1.song.netのように同一ファイルの異なるサブストリームに対応するドメインをSドメインと呼ぶことにする。なお、もしクライアントもしくはＰＳが既存のものとは違って、ＵＲＩ毎にドメイン解決を要求できる場合は、f1578の部分は不要になる。
　上記のように変換されたＵＲＩはユーザが目的のファイルを取得する際に用いるメタデータに書き込まれ、メタデータ記憶部７２に格納される。
　なお、上記の変換でz3という記号を挿入したのは、転送先のＰＳに関するドメイン解決要求を親サイトのDRSに送る際に、同一Fドメインに対応する３つの全てのSドメインのそれぞれについて解決要求のメッセージを送るのではなく、最初にいずれかのＳドメインに関するドメイン解決要求がローカルなＰＳからあったら、ＦドメインについてＰＳ割当てのためのドメイン解決要求をする。これは、例えば次に示すＵＲＩをもつＨＴＴＰリクエストで行うことができる。
　http://(親DRSのアドレス)/PSes?F-domain= z3f1578.site1.song.net.
　これを受信した親DRSは、z3から直ちに３つのSドメインを再生して、それぞれにＰＳを割当てることができる。この３つの組合せは例えば次のように表現できる。
　s1.z3f1578.site1.song.tv　 v.w.x.y1
　s2.z3f1578.site1.song.tv　 v.w.x.y2
　s3.z3f1578.site1.song.tv　 v.w.x.y3
　上記の情報はＸＭＬ形式で記述して親DRSへのＨＴＴＰレスポンスに含めることができる。そしてこのような指定したＵＲＩに対して、そのリソースの状態をＸＭＬファイルで応答するＷｅｂサービスはRESTfulと呼ばれる（非特許文献７）。
　ここで、逐次再生が必要でなく、単純にファイル全体を並列に転送したい場合は、例えばファイル全体を３つのブロックにわけ、変換されたB-URIとしては
　http://s1.z3f1578.site1.song.net/videocast/channel3/item2/block1
　http://s2.z3f1578.site1.song.net/videocast/channel3/item2/block2
　http://s3.z3f1578.site1.song.net/videocast/channel3/item2/block3
というように、サブストリームＩＤとブロックＩＤが１対１のB-URIをサブストリーム総数だけ準備すれば十分である。
　次に、ステップＳ１７３でのメタデータについて説明する。OGSは、次のようなメタデータを作ってメタデータ記憶部７２に格納する。これはクライアントからO-URIを含むHTTPリクエストでアクセスされる。
　Ｏ－ＵＲＩ: http://www.site1.song.net/videocast/channel3/item2/
　エッジサイトDRSのアドレス: 291.47.234.12、291.47.234.13
　サブストリーム１内のB-URI群：
　http://s1.z3f1578.site1.song.net/videocast/channel3/item2/block(3n+1);
　n=0,..,1000
　サブストリーム２内のB-URI群：
　http://s2.z3f1578.site1.song.net/videocast/channel3/item2/block(3n+2);
　n=0…,1000
　サブストリーム３内のB-URI群：
　http://s3.z3f1578.site1.song.net/videocast/channel3/item2/block(3n+3);
　n=0,…,1000
　上記において、ここで番組ファイルを組み立てるために取得すべきブロックに関するB-URIをそのまま全て書き下すとブロック総数が多い場合に情報量が肥大するので、それを防ぐために、サブストリーム毎にパラメトリックな表現を用いている。また、クライアントを誘導すべきエッジサイトのDRSのアドレスは、クライアントがメタデータを要求してきた時点そのクライアントのＩＰアドレス等に基づいて決定される。ここではDRSの障害を考慮して、決定された最適なエッジサイトにおけるDRSのアドレスが２つ記載されている。
　次に、図１７ｂを用いてクライアント処理部１００３の動作について説明する。
ステップＳ１７５で、Webサーバ処理部１００２からメタデータ要求メッセージを渡されたら、ステップＳ１７６で、地理データ記憶部７３とクライアントIPアドレスを参照して、誘導先のエッジサイトのDRSアドレスを決定し、ステップＳ１７７で要求O-URIに対応するB-URI群や発行者が記述したメタデータをメタデータ記憶部から取り出して、DRSアドレスを更に書き加えて、Webサーバ処理部１００２に渡して終了する。
　［ドメイン解決サーバ（DRS）］
　DRSの構成は、第１の実施形態にあるように、分配木の再構成を分散的に行う場合は図５と同じであり、第２の実施形態にあるように分配木の再構成を集中的に行う場合は、図１２と同じである。
　ここで、図１８に、ＤＲＳが有する親ＰＳキャッシュ部のテーブル構成を示す。第１、第２の実施形態では、Ｆドメインと親ＰＳアドレスの組合せを含むエントリを持つのに対して、本実施形態では、同一Ｆドメインに対する各Ｓドメインと親ＰＳアドレスの組合せを含むエントリをもつ。
　次にDRSの動作について説明する。第１の実施形態にあるように、分配木の再構成を分散的に行う場合は、親DRS決定部の動作は図６と同じである。また、第２の実施形態にあるように分配木の再構成を集中的に行う場合は、分配木算出部の動作も図１３と同じである。具体的に、図１９ａ，ｂ，ｃを用いて、分配木の再構成を分散的に行う場合の、PS割当て部８１の動作について説明する。
　図１９ａは、クライアントもしくはローカルＰＳからＳドメインに対するドメイン解決要求があったときの動作を示すフローチャートである。ステップＳ１９１で、クライアントFドメインから親PSアドレスへの解決要求あったら、ステップＳ１９２で、各Sドメインに対して、（１）親PSキャッシュ部にあるアドレスを応答、（２）ない場合は全Sドメインに対してローカルPSを割当てて、応答する。
　ステップＳ１９３で、ローカルPSからSドメインに対する親PSアドレスの解決要求あったら、ステップＳ１９４で、（１）Sドメインに自分と同じOドメインを含む場合は、アドレス解決応答でOGSのアドレスを返す。（２）含まない場合は、親PSキャッシュ部にあるアドレスを応答し、（３）ない場合は親DRS記憶部を参照して、Oドメインに対応する親DRSに、Fドメインから親PSアドレスへの解決要求を送る。ここで、ローカルPSからのドメイン解決要求と応答は、既存のDNSプロトコルを用いて行われる。
　図１９ｂは、PS割当て部８１において、親サイトのDRSからのドメイン解決応答があった、もしくは子サイトのDRSから全てのＳドメインに対するドメイン解決要求があった場合のときの動作を示すフローチャートである。
　ステップＳ１９５で、親サイトのDRSからドメイン解決応答があったら、ステップＳ１９６で、Ｓドメインに対して割当てられたPSのアドレスを親PSキャッシュ部にキャッシュし、解決要求していたローカルPSに対して割当てられたアドレスで応答する。ステップＳ１９７で、子サイトのDRSから全てのＳドメインに対するドメイン解決要求があったら、ステップＳ１９８で、ローカルPS記憶部を参照してロバストハッシングにより各Ｓドメインに対応するPSアドレス群を決定し、解決要求してきた子DRSにそのアドレスを応答して終了する。
　なお、上記ステップＳ１９８におけるロバストハッシングとしては、非特許文献１１もしくは特許文献３の方法に基づいて行う。これは、同じコンテンツが複数のPSに複製されることをなるべく防ぐ一方で、PSが増設もしくは減設されたときに、既存のPSを割当てられているSドメインに別のPSが割当てられるような割合を最小にするためのものである。
　図１９ｃは、PS割当て部８１におけるローカルPSの監視動作を示すものである。ステップＳ１９９で、前回の監視動作から一定時間経過後、タイムアウト回数Ｎを０にして、ローカルPS記憶部にある各PSアドレスに向けてpingを送信する。ステップＳ２００でタイムアウトせずに戻ってきた場合は、そのPSの状態を使用化とする。タイムアウトした場合はNをインクリメントしてpingを再び送信する。そのタイムアウト回数が一定数以上になった場合は、そのPSの状態を使用不可とする。そしてステップＳ１９９に戻る。
　［プロキシサーバ（ＰＳ）］
　次に、本実施形態におけるプロキシサーバ（ＰＳ）について説明する。各サブストリームは個別のドメイン名を持っているので、ローカルサイトの各ＰＳは、ローカルサイトのDRSを使って、サブストリーム単位で親サイトのＰＳアドレスを解決させる。次に、解決された親ＰＳのアドレスに対して単一のＨＴＴＰパーシステントコネクションを設定して、同じサブストリーム内の各ブロックについて、その同一コネクション上をパイプライン形式で、すなわちＢ－ＵＲＩでのブロック番号が大きくなる順番で連続してＨＴＴＰリクエストを出し、ＨＴＴＰレスポンスでブロックのデータを取得する。
　ここでは上述のメタデータに含まれる異なるＵＲＩすなわちブロック単位でＨＴＴＰコネクションを設定することはしない。パーシステントコネクションおよびパイプライニングについては非特許文献１２に記載がある。
　［クライアント］
　次に、本実施形態におけるクライアントについて説明する。図２０に示すように、クライアント４１は、送信装置２２と受信装置２３とデータ処理装置２４と記憶装置１１と入力装置２５と出力装置２１とからからなる。ここで、入力装置２５および出力装置２１は、ユーザが使うものであり、例えばそれぞれキーボード、液晶ディスプレイである。
　データ処理装置２４は、再生処理部２４０２と、表示処理部２４０１と、背景処理部２４０３とからなる。表示処理部２４０１は、ユーザの入力装置２５からの入力信号に基づいて表示を変更し、また再生処理部２４０２から受取ったデータを処理して出力装置２１に渡す。
　背景処理部２４０３は、送受信装置を通じて表示処理部２４０１からの指示でデータの送受信を行う。そのために、エッジサイトのDRSとの間でドメイン解決も行う。なお、背景処理部２４０３と表示処理部２４０１は、Webブラウザの主要な機能に含まれる。
　再生処理部２４０２は、背景処理部２４０３から再生開始の支持があったら、ブロック記憶部１１０１からブロックを順番に取り出し、ビデオであれば復号化を行って出力装置２１に表示する。なお、記憶装置１１は、ブロック記憶部１１０１とメタデータ記憶部１１０２とからなる。
　次に、クライアントの動作について説明する。まず、出力装置２１で示されているＷｅｂ画面上に示された番組アイテムへのリンクに関して、入力装置２５からそのリンクがクリックされた信号が表示処理手段に伝わると、メタデータの要求をＯＲＧに送る。その後表示処理部２４０１は、ＯＧＳからメタデータを取得すると、それをメタデータ記憶部１１０２に格納し、背景処理部２４０３にコンテンツ取得の指示をだす。
　図２１は、クライアントの背景処理部２４０３のその後の動作を説明するためのフローチャートである。ステップＳ２１１で、表示処理部２４０１からコンテンツデータ取得指示を受けたら、ステップＳ２１２で、メタデータ記憶部１１０２からメタデータを取り出して、メタデータのファイル内に記載されたパラメトリックなＵＲＩ群における全てのＳドメインに対してまとめてＰＳのドメイン解決を行う。
　ステップＳ２１３で、ドメイン解決された各PSにパーシステントなＨＴＴＰコネクションを設定し、同じサブストリームに属する異なるブロックに対するHTTPリクエストを、パイプライン形式で転送して終了する。
　ステップＳ２１４で、Ｂ－ＵＲＩに関するＨＴＴＰレスポンスとしてブロックデータを受信したら、ステップＳ２１５で、ブロック記憶部１１０１に格納する。ステップＳ２１６で、取得したブロックがＦドメインに関して先頭ブロックである場合は、再生処理部２４０２に再生開始の指示を行う。
　本実施形態は、以上のような構成により、ファイルをセグメント化してブロック単位で転送する場合でも、サブストリーム単位でドメイン解決をするので、ブロック単位（ここではB-URIで識別される）でドメイン解決を行なう場合に比べてドメイン解決に必要となるメッセージ数を削減することができる。
　さらに、各サブストリームにPSを割当てるためのドメイン解決をまとめて行うので、サブストリーム毎に行う場合に比べてドメイン解決に必要となるメッセージ数を削減することができる。
　また、クライアントとＰＳ間、経路上の１組のＰＳ間では、サブストリーム単位でパーシステントコネクションが設定されて、同じサブストリームに含まれる各ブロックは一旦設定された同一のパーシステントコネクション上を転送するので、非特許文献１におけるように、ＰＳがブロック単位でＨＴＴＰコネクションを設定するのに比べて処理付加や設定遅延を削減することができる。
　次に、本実施形態における動作を説明する。まず、図２２は、ドメイン解決の動作例を示す。クライアントがアクセスするトップページには、メタデータ情報へのリンクが張られている。これはＯ－ＵＲＩをもっている。これをクリックすると、ＯＧＳよりメタデータ（各サブストリーム内のB-URIをパラメトリック表現してある）と、上述した背景処理部２４０３を実現するjavascriptプログラムがダウンロードされる（Ｔ１）。ここで、クライアントのＷｅｂブラウザにおいて動作するプログラムであるＪａｖａｓｃｒｉｐｔについては、非特許文献１３に記述がある。
　次に、クライアントの背景処理部２４０３は、メタデータに含まれるs1,s2,s3のドメインについて、メタデータ内に示されているDRS３０２にまとめてドメイン解決要求すると、それぞれのドメインについて、同一のサイト１０２内に設置された複数のPS、つまり、PS504,505,506のアドレスが解決される（Ｔ２）。
　次に、それぞれ解決されたアドレスをもつPSに対して、パーシステントコネクションを設定し、各サブストリームに含まれる最初のブロックに相当するURIを含むHTTPリクエストを出す（Ｔ３，Ｔ４，Ｔ５）。すると、各PSにはキャッシュが無いので、それぞれのPSはローカルDRS３０２に、それぞれ担当するＳドメインについて、親PSのドメイン解決要求を出す（Ｔ６，Ｔ７，Ｔ８）。
　次に、DRS３０２のＰＳ割当て部は、Ｔ６，Ｔ７，Ｔ８のドメイン解決要求のいずれか一つを最初に受取ったタイミングで、親サイトDRS３０１にFドメインの解決要求を出す（Ｔ９）。これに対して、DRS301がDRS302へ、s1,s2,s3を含む各ドメインにそれぞれPS501、PS502、PS503のアドレスを応答してきたら（Ｔ１０）、PS501, PS502, PS503にそれぞれ対応するPSのアドレスで解決応答する（Ｔ１１，Ｔ１２，Ｔ１３）。これらのPSは、受取った親PSに対してパーシステントコネクションを設定し、サブストリームIDであるs１，s２，s３をそれぞれもつＢ－ＵＲＩを含むHTTPリクエストをHTTP1.1のパイプライン形式で送出する（Ｔ１４，Ｔ１５，Ｔ１６）。
　なお、クライアントも、PSも、URI変換により同じドメイン名をもつサブストリーム内の各ブロックに対しては、最初にそのドメインに対して割当てるべきPSが解決されたら、以降はブロック毎にドメイン解決することなく、HTTPリクエストを出すことができる。
　図２３は、サブストリームの並列転送状況とサブストリーム内のブロック番号の順番を示す説明図である。この場合サブストリームは３つあり、各サブストリームで転送されるブロックとその順番は
　s1： block1, block4, block7 , .... 
　s2： block2, block5, block8, .... 
　s3： block3, block6, block9, .... 
となる。
　オリジンサイト103でst1,st2,st3に割当てたPSは507, 508, 509である。中継サイト101でst1,st2,st3に割当てたPSは501, 502, 503である。エッジサイト102でst1,st2,st3に割当てたPSは504, 505, 506である。クライアント４６の内部において背景処理部が各コネクションからラウンドロビンのように受信したブロックは、クライアント内の再生処理部において順番に組み立て・再生される。
　以上のように、本実施形態では、オリジンサイト１０３が、経路上の同一のサイトに設置された複数のPSに対して、コンテンツを分割したブロック群からなるサブストリームデータを並列配信するため、スループットをより向上させることができる。
　なお、上記では、実施形態１，２で説明したように、ドメイン解決サーバにて設定した有向分配木に基づく経路に従って、同一サイト上の複数のPSに対して複数のサブストリームデータを並列転送する場合を説明したが、予め設定された経路に従って、同一サイト上の複数のPSに対して、複数のサブストリームデータを並列転送してもよい。
　＜実施形態４＞
　次に、本発明の第４の実施形態について図面を参照して詳細に説明する。本実施形態では、クライアントがブラウザ上から設定できるHTTPコネクション数が限られている場合に、転送網内では、その定数倍のサブストリームを用いて高速転送する、という構成を有している点に特徴を有する。
　図２４は、サイトの構成を説明する図である。第１の実施形態に加えて、あらたにサイト内に変換サーバ（中継サーバ）２３０１，２３０２（以下、「ＴＳ」と呼ぶ）が加わる。この変換サーバ２３０１，２３０２は、コネクション設定数に制限のあるクライアントとのデータのやり取りを直接行うと共に、同じサイト内のPSとHTTPコネクションを設定してデータのやり取りをおこなう。これにより、TSはサブストリームの載せ替えを行う。具体的には、PSとの間で、所定のセッション数にてサブストリームデータの送受信を行うと共に、クライアントに対しては、当該クライアントが接続可能なセッション数の上限数の範囲内にサブストリームデータを集約して、クライアントに転送する機能（転送手段）を有する。
　ただし、TSはPSと違ってURIで区別できるブロックのキャッシュは行わない。TSとPSには異なるIPアドレスが付与され、DRS３０２は、送られてきたデータのソースアドレスをみてTSとPSを区別することができるものとする。
　図２５は、DRS３０２のPS割当て部の動作を示すフローチャートである。ここでは、第３の実施形態と異なる部分について説明する。図１９ａを変形して次のようになる。
　ステップＳ２５１で、クライアントからFドメインの解決要求がHTTPリクエストとしてあったら、ステップＳ２５２で、該当する全SドメインのそれぞれにTSを割当てて、そのアドレスを返す。ただし、異なるTSのアドレスは、クライアントのコネクション設定上限数以下になるようにする。
　ステップＳ２５３で、TSからSドメインの解決要求があったら、ステップＳ２５４で、対応するSドメインに割当てたローカルPSがローカルPSキャッシュ部にある場合はそれを応答し、ない場合はロバストハッシングにより全てのSドメインに対してローカルPSを割り当ててそのアドレスを応答する。
　ステップＳ２５５で、ローカルなPSからSドメインに関して解決要求があったら、ステップＳ２５６で、（１）（２）親PSキャッシュ部を参照して応答し、（３）無い場合は、Oドメインに対応する親DRSに、全てのSドメインに対する親PSのドメイン解決要求をする。TSはPSと同じ動作をするが、ＰＳはＨＴＴＰレスポンスが戻って来たらそのデータをキャッシュしてもよいが、ＴＳはキャッシュしない。
　ステップＳ２５６におけるロバストハッシングとしては、非特許文献１１もしくは特許文献３の方法に基づいて行う。これは、同じコンテンツが複数のPSに複製されることをなるべく防ぐ一方で、PSが増設もしくは減設されたときに、既存のPSを割当てられているSドメインに別のPSが割当てられるような割合を最小にするためのものである。
　本実施形態は、以上のように構成することにより、サブストリームを載せ替えるためのTSをPSとクライアントの間に入れるので、クライアントにHTTPコネクション設定数の上限があっても、これとは独立に、分配網内では並列転送するサブストリーム総数を設定してスループットの向上を図ることができる。
　次に、第４の実施形態における実施例について説明する。図２６は、クライアント４５、DRS３０２, TS２３０１，２３０２、PS５０１～５０６の間の連携動作を示す図である。ここではクライアントが終端できるHTTPコネクションが「２」であるのに対して、転送網内ではサブストリーム総数を「６」として並列転送を行うようにTSサーバがサブストリームの載せ換えを行う。
　以下IDがnであるサブストリームをssnと略記することにする。
　クライアントはコネクション数上限「２」で、メタデータ内で指定されたDRS３０２にFドメインの解決を要求すると、ss1, ss2, ss3にはTS２３０１のアドレスを、ss4, ss5, ss6にはTS2302のアドレスで解決応答されてくる。するとクライアントは、TS2301およびTS2302にそれぞれパーシステントコネクションを設定して、ss1, ss2, ss3 およびss4, ss5, ss6に属するブロックのURI（B-URI）を含むHTTPリクエストをパイプライン形式で送信する。すなわち、ＴＳ２３０１へは、
　block1, block2, block3, block7, block8, block9,…
にそれぞれ対応するB-URIを含むＨＴＴＰリクエストをその順番でＴＳ２３０１に送る。
　また、ＴＳ２３０２には
　block4, block5, block6, block10, block11, block12,…
にそれぞれ対応するB-URIを含むＨＴＴＰリクエストをその順番でＴＳ２３０２に送る。
　これらを受取ったTS２３０１は、ss1, ss2, ss3の各サブストリームIDを含むＢ－ＵＲＩを始めて検出したら、DRS３０２に各Sドメインの解決要求を転送する。同様にして、TS230２は各Sドメインの解決要求をDRS３５に転送する。これらの要求はDNSプロトコルを用いて行われる。
　そして、DRS３０２は、ss1, ss2, ss3に関する各Sドメインの解決要求に対してPS501、PS502、PS502を割当ててTS2301に応答したとする。またDRS302はss4, ss5, ss6に関する各Sドメインの解決要求に対してPS504、PS505、PS506をそれぞれ割当ててTS2302に応答したとする。するとTS2301はPS501, PS502, PS503に対してパーシステントコネクションを設定して、各Sドメインに対応するB-URIを含むリクエストを対応する各パーシステントコネクション上に転送する。
　同様に、TS2302は、PS504, PS505, PS506に対してそれぞれパーシステントコネクションを設定して、各ドメインに対応するB-URIを含むリクエストを対応する各パーシステントコネクション上に転送する。PSは自分がデータを保持する場合は、TSにブロックを返すが、無い場合はDRSに親サイトのPSのドメイン解決を要求する。
　なお、上記各実施形態においてプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されている。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。
　以上、上記各実施形態を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることができる。
　なお、本発明は、日本国にて２０１０年９月２日に特許出願された特願２０１０－１９６４１６の特許出願に基づく優先権主張の利益を享受するものであり、当該特許出願に記載された内容は、全て本明細書に含まれるものとする。
＜付記＞
　上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるデータ転送システムの構成の概略を、図２７及び図２８のブロック図を参照して説明する。また、本発明におけるプログラム、情報処理方法等の構成の概略について説明する。但し、本発明は、以下の構成に限定されない。
（付記１－１：図２７参照）
　コンテンツが蓄積されたオリジンサーバ５０１０と、要求されたコンテンツを転送する複数のプロキシサーバ５０２０と、クライアント６０００がデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバ５０３０と、を設置したサイト５０００，５１００，５２００が、ネットワークを介して複数接続されており、
　前記ドメイン解決サーバ５０３０が、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段５０３１と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段５０３２と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段５０３３と、を備え、
　前記経路設定手段５０３２は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
　前記割り当て手段５０３３は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である親サイトにあるプロキシサーバを自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
データ転送システム。
（付記１－２）
　付記１－１に記載のデータ転送システムであって、
　前記計測手段は、各サイトに設置されたドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
データ転送システム。
（付記１－３）
　付記１－２に記載のデータ転送システムであって、
　前記計測手段は、前記リンクパラメータとして、前記各サイトにそれぞれ設置された前記各ドメイン解決サーバ間におけるラウンドトリップタイムを計測し、
　前記経路決定手段は、前記各経路上における各サイト間のラウンドトリップタイムのうちの最大値が最小となる経路を設定する、
データ転送システム。
（付記１－４）
　付記１－２に記載のデータ転送システムであって、
　前記計測手段は、前記リンクパラメータとして、前記各サイトにそれぞれ設置された前期各ドメイン解決サーバ間におけるラウンドトリップタイムを計測し、
　前記経路決定手段は、前記各経路上における各サイト間のラウンドトリップタイムの総和が最小となる経路を設定する、
データ転送システム。
（付記１－５）
　付記１－２乃至１－４のいずれかに記載のデータ転送システムであって、
　前記ドメイン解決サーバの前記計測手段は、他のドメイン解決サーバに対して、自己であるドメイン解決サーバと他のドメイン解決サーバとの間における前記リンクパラメータを計測すると共に、この計測時に、他のドメイン解決サーバに対して当該他のドメイン解決サーバが既に計測した計測結果を要求して取得する、
データ転送システム。
（付記１－６）
　付記１－１乃至１－５のいずれかに記載のデータ転送システムであって、
　前記ドメイン解決サーバが備える前記計測手段と前記経路設定手段とは、予め設定されたタイミングで作動して、経路及び親ドメイン解決サーバの設定を行う、
データ転送システム。
（付記１－７）
　付記１－１乃至１－６のいずれかに記載のデータ転送システムであって、
　前記各サイトの各ドメイン解決サーバが備えた前記経路設定手段は、自サイトの前記オリジンサーバが記憶されているコンテンツを配信する経路を決定すると共に、前記親ドメイン解決サーバを決定して、他のドメイン解決サーバに通知し、前記他のドメイン解決サーバは、それに基づいて親ドメイン解決サーバを設定する、
データ転送システム。
（付記１－８）
　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバであって、
　各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を備え、
　前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
　前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
ドメイン解決サーバ。
（付記１－９）
　付記１－８に記載のドメイン解決サーバであって、
　前記計測手段は、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
ドメイン解決サーバ。
（付記１－１０）
　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバに組み込まれるプログラムであって、
　前記ドメイン解決サーバに、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を実現すると共に、
　前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
　前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
プログラム。
（付記１－１１）
　付記１－１０に記載のプログラムであって、
　前記計測手段は、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
プログラム。
（付記１－１２）
　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおけるデータ転送方法であって、
　前記ドメイン解決サーバが、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測し、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定し、前記ドメインに対応するプロキシサーバを割り当てると共に、
　前記経路設定時に、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
　前記割り当て時に、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
データ転送方法。
（付記１－１３）
　付記１－１２に記載のデータ転送方法であって、
　前記リンクパラメータの計測時に、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
データ転送方法。
（付記２－１：図２８参照）
　コンテンツが蓄積されたオリジンサーバ７０１０と、要求されたコンテンツを転送する複数のプロキシサーバ７０２０と、クライアント８０００がデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバ７０３０と、を設置したサイト７０００，７１００，７２００が、ネットワークを介して複数接続されており、
　前記オリジンサーバ７０１０は、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが１つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段７０１１を備え、
　前記ドメイン解決サーバ７０３０は、前記各サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段７０３１を備え、
　前記割り当て手段７０３１は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームのドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求をするときに、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、
データ転送システム。
（付記２－２）
　付記２－１に記載のデータ転送システムであって、
　前記オリジンサーバが有する前記コンテンツ処理手段は、前記各ブロックには、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームのドメインを含む識別子を付与する、
データ転送システム。
（付記２－３）
　付記２－１又は２－２に記載のデータ転送システムであって、
　前記オリジンサーバが有する前記コンテンツ処理手段は、前記サブストリームの総数を含む前記識別子を、前記ブロックに付与する、
データ転送システム。
（付記２－４）
　付記２－１乃至２－３のいずれかに記載のデータ転送システムであって、
　前記クライアントがアクセスしたエッジサイトにおいて、前記クライアントと前記プロキシサーバとの間に、前記コンテンツを転送する中継サーバを備え、
　前記ドメイン解決サーバの割り当て手段は、前記クライアントのドメイン解決要求に対して、前記クライアントが設定可能なコネクション数の上限以内の中継サーバを割当てる、
データ転送システム。
（付記２－５）
　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記オリジンサーバであって、
　コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが１つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段を備え、
　前記コンテンツ処理手段は、前記各ブロックに、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームに対応するドメインを含む識別子を付与する、
オリジンサーバ。
（付記２－６）
　付記２－５に記載のオリジンサーバであって、
　前記コンテンツ処理手段は、サブストリームの総数を含む前記識別子を、前記ブロックに付与する、
オリジンサーバ。
（付記２－７）
　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記オリジンサーバに組み込まれるプログラムであって、
　前記オリジンサーバに、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが１つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段を実現させると共に、
　前記コンテンツ処理手段は、前記各ブロックに、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームに対応するドメインを含む識別子を付与する、
プログラム。
（付記２－８）
　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記ドメイン解決サーバであって、
　前記オリジンサーバにて、コンテンツを分割してできるブロックに、当該ブロックが１つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子が付与されており、
　前記サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段を備え、
　前記割り当て手段は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームに対応するドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの所与の経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求において、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、
ドメイン解決サーバ。
（付記２－９）
　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記ドメイン解決サーバに組み込まれるプログラムであって、
　前記オリジンサーバにて、コンテンツを分割してできるブロックに、当該ブロックが１つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子が付与されており、
　前記ドメイン解決サーバに、前記サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段を実現すると共に、
　前記割り当て手段は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームに対応するドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの所与の経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求において、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、
プログラム。
（付記２－１０）
　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおけるデータ転送方法であって、
　前記オリジンサーバが、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが１つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与し、
　前記ドメイン解決サーバが、前記各サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定し、
　前記ドメイン解決サーバによるプロキシサーバの割り当て時に、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームのドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求をするときに、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、
データ転送方法。
（付記２－１１）
　付記２－１０に記載のデータ転送方法であって、
　前記オリジンサーバが前記ブロックに識別子を付与するときに、前記各ブロックには、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームのドメインを含む識別子を付与する、
データ転送方法。
　以上のように、本発明は、ネットワーク運用単位であるASの多数から構成されるインターネット上に地理的に分散配置された複数のサーバサイトもしくはデータセンタからのコンテンツデータの配信サービスやアプリケーションデータの配信サービスといった用途に適用できる。また、本発明によれば、オリジンサイトからエッジサイト間へのコンテンツの分配のみならず、OGSのアプリケーションで処理した結果を、１つもしくは複数の中継サイトを経由してエンドユーザのWebクライアントに転送するアプリケーション配信にも使える。
１０１～１０４　サイト
２０２，２０４　オリジンサーバ（OGS）
　１２　送信装置
　１３　受信装置
　１０　処理装置
　１００１　発行処理部
　１００２　Webサーバ処理部
　１００３　クライアント処理部
　７　記憶装置
　７１　ブロック記憶部
　７２　メタデータ記憶部
　７３　地理データ記憶部
３０１～３０４　ドメイン解決サーバ（DRS）
　１４　送信装置
　１５　受信装置
　８　データ処理装置
　８１　ＰＳ割り当て部
　８２　親ＤＲＳ決定部
　８３　分配木算出部
　９　記憶装置
　９１　ローカルＰＳ記憶部
　９２　親ＰＳキャッシュ部
　９３　親ＤＲＳ記憶部
　９４　ＲＴＴ行列記憶部
　９５　ＲＴＴ統計記憶部
　９６　分配木記憶部
４１～４５　クライアント
　２１　出力装置
　２２　送信装置
　２３　受信装置
　２４　データ処理装置
　２５　入力装置
　２４０１　表示処理部
　２４０２　再生処理部
　２４０３　背景処理部
　１１　記憶装置
　１１０１　ブロック記憶部
　１１０２　メタデータ記憶部
５０１～５１２　プロキシサーバ（PS）
１８　サブネットワーク
１９　マルチレイヤスイッチ
２０　エッジルータ
２３０１，２３０２　変換サーバ（ＴＳ）
 

Claims (13)

  1. 　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されており、
    　前記ドメイン解決サーバが、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を備え、
    　前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
    　前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である親サイトにあるプロキシサーバを自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
    データ転送システム。
  2. 　請求項１に記載のデータ転送システムであって、
    　前記計測手段は、各サイトに設置されたドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
    データ転送システム。
  3. 　請求項２に記載のデータ転送システムであって、
    　前記計測手段は、前記リンクパラメータとして、前記各サイトにそれぞれ設置された前記各ドメイン解決サーバ間におけるラウンドトリップタイムを計測し、
    　前記経路決定手段は、前記各経路上における各サイト間のラウンドトリップタイムのうちの最大値が最小となる経路を設定する、
    データ転送システム。
  4. 　請求項２に記載のデータ転送システムであって、
    　前記計測手段は、前記リンクパラメータとして、前記各サイトにそれぞれ設置された前期各ドメイン解決サーバ間におけるラウンドトリップタイムを計測し、
    　前記経路決定手段は、前記各経路上における各サイト間のラウンドトリップタイムの総和が最小となる経路を設定する、
    データ転送システム。
  5. 　請求項２乃至４のいずれかに記載のデータ転送システムであって、
    　前記ドメイン解決サーバの前記計測手段は、他のドメイン解決サーバに対して、自己であるドメイン解決サーバと他のドメイン解決サーバとの間における前記リンクパラメータを計測すると共に、この計測時に、他のドメイン解決サーバに対して当該他のドメイン解決サーバが既に計測した計測結果を要求して取得する、
    データ転送システム。
  6. 　請求項１乃至５のいずれかに記載のデータ転送システムであって、
    　前記ドメイン解決サーバが備える前記計測手段と前記経路設定手段とは、予め設定されたタイミングで作動して、経路及び親ドメイン解決サーバの設定を行う、
    データ転送システム。
  7. 　請求項１乃至６のいずれかに記載のデータ転送システムであって、
    　前記各サイトの各ドメイン解決サーバが備えた前記経路設定手段は、自サイトの前記オリジンサーバが記憶されているコンテンツを配信する経路を決定すると共に、前記親ドメイン解決サーバを決定して、他のドメイン解決サーバに通知し、前記他のドメイン解決サーバは、それに基づいて親ドメイン解決サーバを設定する、
    データ転送システム。
  8. 　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバであって、
    　各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を備え、
    　前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
    　前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
    ドメイン解決サーバ。
  9. 　請求項８に記載のドメイン解決サーバであって、
    　前記計測手段は、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
    ドメイン解決サーバ。
  10. 　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバに組み込まれるプログラムであって、
    　前記ドメイン解決サーバに、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を実現すると共に、
    　前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
    　前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
    プログラム。
  11. 　請求項１０に記載のプログラムであって、
    　前記計測手段は、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
    プログラム。
  12. 　コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおけるデータ転送方法であって、
    　前記ドメイン解決サーバが、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測し、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定し、前記ドメインに対応するプロキシサーバを割り当てると共に、
    　前記経路設定時に、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
    　前記割り当て時に、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
    データ転送方法。
  13. 　請求項１２に記載のデータ転送方法であって、
    　前記リンクパラメータの計測時に、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
    データ転送方法。
     
PCT/JP2011/004665 2010-09-02 2011-08-23 データ転送システム WO2012029247A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/818,147 US20130151664A1 (en) 2010-09-02 2011-08-23 Data transfer system
JP2012531671A JP5803924B2 (ja) 2010-09-02 2011-08-23 データ転送システム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010-196416 2010-09-02
JP2010196416 2010-09-02

Publications (1)

Publication Number Publication Date
WO2012029247A1 true WO2012029247A1 (ja) 2012-03-08

Family

ID=45772374

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/004665 WO2012029247A1 (ja) 2010-09-02 2011-08-23 データ転送システム

Country Status (3)

Country Link
US (1) US20130151664A1 (ja)
JP (1) JP5803924B2 (ja)
WO (1) WO2012029247A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10715484B1 (en) * 2019-12-11 2020-07-14 CallFire, Inc. Domain management and synchronization system
JP7248600B2 (ja) * 2020-01-21 2023-03-29 株式会社日立製作所 計算機システム及びデータ転送の制御方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009522877A (ja) * 2005-12-30 2009-06-11 アカマイ テクノロジーズ，インク． 任意のデータフロー用の高信頼性、高スループット、高パフォーマンス転送及びルーティングメカニズム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6108703A (en) * 1998-07-14 2000-08-22 Massachusetts Institute Of Technology Global hosting system
US6820133B1 (en) * 2000-02-07 2004-11-16 Netli, Inc. System and method for high-performance delivery of web content using high-performance communications protocol between the first and second specialized intermediate nodes to optimize a measure of communications performance between the source and the destination
US7424526B1 (en) * 2001-07-31 2008-09-09 Sprint Communications Company L.P. Internet service node incorporating a bandwidth measurement device and associated methods for evaluating data transfers
DE60213623T2 (de) * 2002-12-09 2007-10-18 Tektronix International Sales Gmbh Umlaufzeitabschätzungsverfahren und Einrichtung mittels Rückquittierung in einem Paketübertragungssystem

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009522877A (ja) * 2005-12-30 2009-06-11 アカマイ テクノロジーズ，インク． 任意のデータフロー用の高信頼性、高スループット、高パフォーマンス転送及びルーティングメカニズム

Also Published As

Publication number Publication date
JPWO2012029247A1 (ja) 2013-10-28
US20130151664A1 (en) 2013-06-13
JP5803924B2 (ja) 2015-11-04

Similar Documents

Publication Publication Date Title
US9769072B2 (en) Method and apparatus for scalable content routing and mobility in named data networks
US7978631B1 (en) Method and apparatus for encoding and mapping of virtual addresses for clusters
JP5050095B2 (ja) Ｐ２ｐコンテンツ共有のための方法、システム、及びノード
US9515920B2 (en) Name-based neighbor discovery and multi-hop service discovery in information-centric networks
CN102984289B (zh) 促进nat穿透的方法以及移动设备
US10263950B2 (en) Directing clients based on communication format
US20140173018A1 (en) Content Based Traffic Engineering in Software Defined Information Centric Networks
TWI584194B (zh) 在一服務導向架構（ｓｏａ）網路中尋求服務之技術
US20120191769A1 (en) Site-aware distributed file system access from outside enterprise network
Xie et al. Supporting seamless virtual machine migration via named data networking in cloud data center
JP5716745B2 (ja) データ転送システム
JP5803924B2 (ja) データ転送システム
CN101584192B (zh) 节点注册方法
Ijaz et al. A survey and comparison on overlay‐underlay mapping techniques in peer‐to‐peer overlay networks
Silva et al. A holistic SDN-capable session-plane tailored for efficient IoMT smart surveillance applications
JP2011150382A (ja) コンテンツ配信システムと方法およびプログラム
JP5726302B2 (ja) トポロジサーバを用いた、通信アーキテクチャにわたって分散されたノードのネットワークに対する秘密または保護されたアクセス
Xing et al. SD-ICN: Toward wide area deployable software defined information centric networking
Stevens et al. Analysis of an anycast based overlay system for scalable service discovery and execution
Banerjee et al. The survey, research challenges, and opportunities in ICN
JP2012089015A (ja) 分散情報処理システム、分散情報処理方法及びデータ転送装置
JP2016046785A (ja) キャッシュサーバ選択装置、分散キャッシュシステム、及びキャッシュサーバ選択方法
Wang et al. NCDN: A Node-Failure Resilient CDN Solution with Reinforcement Learning Optimization
Dulal NDNSD: Service publishing and discovery in NDN
Rubambiza et al. EdgeRDV: A Framework for Edge Workload Management at Scale

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11821272

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2012531671

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 13818147

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11821272

Country of ref document: EP

Kind code of ref document: A1